Ralf Angeli <[EMAIL PROTECTED]> writes: > * 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 think we should have one mechanism for doing this kind of stuff. > Of course this could provide different interfaces for the user. One problem I see with this is that it has _major_ overlap with the input functionality of X-Symbol <URL:http://x-symbol.sf.net>. I don't know whether this is intentional, but I think that the X-Symbol functionality in this regard was very well designed (it also offers tables from which to pick symbols and various other stuff). Now the principal idea of X-Symbol's operation has been the replacement of control sequences like \"a in the buffer with รค and in particular doing so for a large number of mathematical symbols (implemented via separate fonts), and this kind of operation is bound to inserting the actual symbols, not corresponding control sequences. The input methods are just an "additional" functionality. So the input methods would need some working over in order to only insert symbols that are known to work with the current document encoding, and use the TeX transliteration otherwise. Or always insert the transliteration. I think it would make sense to steal the (really well-designed) input method functionality from X-Symbol. It would require a copyright assignment from Christoph, of course, and we should take care to ensure that those people who actually use X-Symbol can do so (and switch it on and off) without AUCTeX disrupting its information. Christoph, any comments? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum _______________________________________________ auctex-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/auctex-devel
