unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: David Kastrup <dak@gnu.org>
Cc: monnier@iro.umontreal.ca, Lute.Kamstra.lists@xs4all.nl,
	emacs-devel@gnu.org
Subject: Re: Removing unloaded functions from auto-mode-alist.
Date: Thu, 21 Apr 2005 19:46:11 +0200	[thread overview]
Message-ID: <85br88qazg.fsf@lola.goethe.zz> (raw)
In-Reply-To: <E1DOdd7-0005k4-GK@fencepost.gnu.org> (Richard Stallman's message of "Thu, 21 Apr 2005 11:30:13 -0400")

Richard Stallman <rms@gnu.org> 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

  reply	other threads:[~2005-04-21 17:46 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-19 15:23 Removing unloaded functions from auto-mode-alist Lute Kamstra
2005-04-19 16:25 ` David Kastrup
2005-04-19 17:44   ` Stefan Monnier
2005-04-19 21:28     ` David Kastrup
2005-04-19 21:58       ` Stefan Monnier
2005-04-19 22:33         ` David Kastrup
2005-04-20 18:52           ` Stefan Monnier
2005-04-24 20:24             ` Lute Kamstra
2005-04-24 20:50               ` David Kastrup
2005-04-24 21:51                 ` Lute Kamstra
2005-04-24 22:00                   ` David Kastrup
2005-04-24 23:37                     ` Lute Kamstra
2005-04-25  0:07                       ` David Kastrup
2005-04-26 10:04                       ` Richard Stallman
2005-04-20 19:22           ` Lute Kamstra
2005-04-19 23:01         ` Stefan Monnier
2005-04-19 23:14         ` Lute Kamstra
2005-04-19 23:24           ` David Kastrup
2005-04-20 18:41             ` Stefan Monnier
2005-04-20 19:00               ` David Kastrup
2005-04-20 19:18                 ` Stefan Monnier
2005-04-20 19:50                   ` David Kastrup
2005-04-20 19:29               ` Lute Kamstra
2005-04-20 14:57           ` Richard Stallman
2005-04-20 15:59             ` Lute Kamstra
2005-04-21 15:30               ` Richard Stallman
2005-04-21 16:35                 ` Lute Kamstra
2005-04-22 20:51                   ` David Kastrup
2005-04-23 21:00                     ` Lute Kamstra
2005-04-23 22:10                       ` David Kastrup
2005-04-24 20:21                         ` Lute Kamstra
2005-04-24 20:32                           ` David Kastrup
2005-04-24 20:52                             ` Lute Kamstra
2005-04-25 16:05                             ` Richard Stallman
2005-04-23 22:24                     ` Richard Stallman
2005-04-20 14:57         ` Richard Stallman
2005-04-20 15:02           ` Stefan Monnier
2005-04-20 15:57             ` David Kastrup
2005-04-20 18:37               ` Stefan Monnier
2005-04-20 19:19                 ` David Kastrup
2005-04-20 20:11                   ` Stefan Monnier
2005-04-20 20:25                     ` David Kastrup
2005-04-20 20:57                       ` Stefan Monnier
2005-04-20 21:33                         ` David Kastrup
2005-04-20 16:25             ` Andreas Schwab
2005-04-20 16:57               ` David Kastrup
2005-04-20 22:47                 ` Andreas Schwab
2005-04-20 22:58                   ` David Kastrup
2005-04-21  9:56                     ` Andreas Schwab
2005-04-21 10:12                       ` David Kastrup
2005-04-21 11:50                         ` Andreas Schwab
2005-04-21 19:56                         ` Richard Stallman
2005-04-21 20:13                           ` David Kastrup
2005-04-23 16:15                             ` Richard Stallman
2005-04-23 16:23                               ` David Kastrup
2005-04-23 16:15                           ` Richard Stallman
2005-04-21 11:41                       ` Johan Vromans
2005-04-20 15:43           ` David Kastrup
2005-04-21 15:30             ` Richard Stallman
2005-04-21 17:46               ` David Kastrup [this message]
2005-04-23 16:15                 ` Richard Stallman
2005-04-19 22:00       ` Lute Kamstra
2005-04-19 23:22       ` Andreas Schwab
2005-04-19 23:33         ` David Kastrup
2005-04-19 21:05   ` Lute Kamstra
2005-04-20 14:57     ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=85br88qazg.fsf@lola.goethe.zz \
    --to=dak@gnu.org \
    --cc=Lute.Kamstra.lists@xs4all.nl \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).