Richard Stallman <[EMAIL PROTECTED]> writes: > So they SHOULD be invoked by the same names. > > I explained already why nothing else makes sense. AUCTeX makes > extensive use of mode cookies in local variables, and those are only > obeyed in the lowercase version. The choice of AUCTeX vs tex-mode is > a user preference and should not be embedded into files. > > That is right. > > It would be feasible to set up AUCTeX and tex-mode.el so that they > have no overlap except for the primary entry points, which are > tex-mode etc. and TeX-mode etc.
That is already the case: AUCTeX uses the mixed case variants exclusively, _except_ when it calls one of its modes that _might_ be subjected to user choice. All of AUCTeX's mode hooks and variables also use the lowercase version. So if one bothers fiddling with load order and realiasing, one can indeed choose plain-tex-mode from tex-mode.el, but LaTeX-mode from AUCTeX. > However, this package and its user options could just as well be > included in AUCTeX. I see no benefit in making it a separate file. Yes. That's the current setup, anyway: requiring tex-site.el will make AUCTeX replace the respective variables. I am at the moment just concerned with creating a setup where Emacs packagers would have no qualms enabling AUCTeX as the default mode by preloading "auctex.el" (to be created). And this goal can be achieved if (unload-feature 'auctex) or something similar will remove it again. Another possibility would be to have a customizable variable AUCTeX-modes which contains all modes that should be provided by AUCTeX. Psychologically however, (setq AUCTeX-modes nil) means that you have to beg AUCTeX to be gone, whereas (unload-feature 'AUCTeX) commands it to be gone. People objecting to AUCTeX might prefer the second variant on principle as long as one does not tell them that it only works because it wants to... Maybe I'll try combining both approaches: if I am saving the function cells of both the AUCTeX modes and tex-mode.el after loading, restoring via auctex-unload-hook should also be possible. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum _______________________________________________ Emacs-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/emacs-devel
