[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [AUCTeX-devel] New tex-symb.el

From: Ralf Angeli
Subject: Re: [AUCTeX-devel] New tex-symb.el
Date: Sun, 04 Feb 2007 09:27:30 +0100
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.93 (gnu/linux)

* Masayuki Ataka (2007-02-04) writes:

> I brushed up my tex-symb.el, that is posted here two years ago.
> I attached new tex-symb.el at the end of this mail.
> tex-symb provieds two abbrev expand commands.
> 1. Greek expansion (TeX-symb-greek-expand)
>   a C-.  ->  \alpha
> 2. Symbol expansion (TeX-symb-symbol-expand)
>   oo C-,  ->  \infty

What is the reason for having two different postfix key bindings?
BTW, these key bindings should be reserved for minor modes.

> I prepared abbrev rules for almost LaTeX math symbols

I find it a bit unfortunate that additional lists are used which
contain strings already present in `LaTeX-math-default'.  Wouldn't it
be possible to integrate LaTeX Math mode and tex-symb and operate on a
single data source for math macros?

One could have one minor mode where one could switch between the
different kind of key bindings (prefix, postfix) or this could be
implemented as two kinds of input methods.

Also, regarding the macros, at one day I'd like to have a single
database of macros with all related information which can be used by
various parts of AUCTeX.  For example with information on arguments to
be used in connection with `C-c RET'.  Similarly with information on
syntax to be used in connection with font locking.  With information
to be displayed as documentation of the macro for the user.  And so
on.  Perhaps that could be kept in mind.

> (including
> amssymb!).

Could this be moved to the respective style file?

> I would like to add tex-symb.el into AUCTeX distribution for
> the third Math symbol aid tool (The first and second tools are
> Menu and LaTeX-math-mode).  Developers, how do you think?

I think we should have one mechanism for doing this kind of stuff.  Of
course this could provide different interfaces for the user.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]