Re: My resignation from Emacs development

[Eli Zaretskii <eliz@gnu.org>]

> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Sat, 23 Nov 2024 01:10:30 -0500
> 
>   > Names are important.  They have power.  To take somebody's/somthing's
>   > name and misuse it is an exercise of aggression.  Try using "Emacs" or
>   > even "free software" to mean something different, and see just how
>   > quickly you would hear back from Richard Stallman.
> 
> Is this really the case?  I am trying to figure out what concrete events
> those descriptions could refer to, and I can't be sure.

If I may summarize those events and the technical aspects of this,
they are as follows:

 . Emacs 29 introduced a new user option called
   major-mode-remap-alist.  It allows to "remap" one major mode into
   another, and is obeyed by normal-mode, so if FOO-mode is remapped
   to BAR-mode, then any time FOO-mode is found to be appropriate for
   a buffer, whether by virtue of auto-mode-alist, or file-local
   variables, or anything else, normal-mode would actually activate
   BAR-mode instead.
 . When we added to Emacs major modes based on the tree-sitter library
   for programming languages for which we already had "traditional"
   major modes, this mode remapping was suggested as the means for
   users to express their preference of using the tree-sitter modes
   (which by default are disabled, as auto-mode-alist still names the
   traditional modes for the respective file types, to preserve past
   behavior and avoid surprising users).  I disagreed with using this
   feature, because the value of major-mode-remap-alist is not simple
   enough for users to customize.  Instead, we arranged for the
   tree-sitter modes to modify auto-mode-alist when the mode is
   loaded, and told users that by loading the mode manually, they will
   have their preference be known to Emacs.
 . Changing global data structure, such as auto-mode-alist, when a
   Lisp package is merely loaded is not the best idea, and has some
   negative consequences.  For example, byte-compiling a package in a
   running Emacs session loads that package, and thus might modify
   auto-mode-alist when the user didn't really mean that.  And getting
   auto-mode-alist back to its previous value is not easy, unless you
   are a Lisp programmer.  Moreover, modifying auto-mode-alist doesn't
   affect visiting files that have a mode cookie or set their
   major-mode in the file-local variables.  So this solution had known
   issues, but was still used for its simplicity in the typical use
   case, where the user starts a session and wants to switch to using
   a certain tree-sitter mode from that moment onwards.
 . In March 2024 Stefan Monnier installed a change for Emacs 30 that
   introduced a new variable, major-mode-remap-defaults.  This
   variable is consulted by normal-mode if major-mode-remap-alist
   (which is a user option, and thus can be changed only by users)
   doesn't have any associations for a mode, and if
   major-mode-remap-defaults does have such an association, the mode
   is remapped as described above.  Stefan then used this new variable
   to replace the code which modified auto-mode-alist when a
   tree-sitter mode was loaded.  Specifically, when c-ts-mode is
   loaded, it adds associations to major-mode-remap-defaults that
   remap c-mode and c++-mode to their tree-sitter counterparts; and
   when ruby-ts-mode is loaded, it adds associations that remap
   ruby-mode to its tree-sitter counterpart.  The main motivation for
   these changes was that they make the process of preferring a
   tree-sitter mode by the user cleaner, by not messing with
   auto-mode-alist, and by making sure normal-mode will _always_ use
   the preferred mode.  This change was discussed (as part of
   bug#69191), but it should have been discussed more, and in
   particular its effects on normal-mode and its callers should have
   been explicitly described and discussed.
 . In May 2024 Alan Mackenzie installed in cc-mode.el a change that
   countermanded the use of major-mode-remap-defaults for remapping
   c-mode and c++-mode to the tree-sitter counterparts.  The change he
   installed defeated the code in c-ts-mode which added associations
   to major-mode-remap-defaults.  The result was that loading
   c-ts-mode no longer had the effect of using c-ts-mode for C files,
   contrary to the documentation which said it would.  The exact way
   this change worked was never described anywhere but the commit log
   message, although the change itself was announced in a message
   posted by Alan to emacs-devel
   (https://lists.gnu.org/archive/html/emacs-devel/2024-05/msg01294.html).
   Needless to say, the adverse effects of that change on people who
   prefer using c-ts-mode went unknown until Emacs 30 went into
   pretest.  When asked (in bug#74339) to fix that code which allowed
   the documented procedure for users to express their preference for
   c-ts-mode to work, Alan said he will not agree to such a change,
   and proposed other ways of solving this, which would go back to
   using auto-mode-alist (something which we already decided we want
   to abandon in favor of better ways) and would delay the release of
   Emacs 30.1 due to non-trivial changes in data structures and code
   central to Emacs as a whole, not just to these two modes.

I will leave it to Alan to describe why he thinks the mode-remapping
feature is wrong when it affects c-mode, and/or why it is wrong to do
that via major-mode-remap-defaults.  From my POV, mode-remapping is
just a convenience feature which allows users to substitute one mode
for another without a lot of modifications in auto-mode-alist and
similar data strictures used by normal-mode, editing all the files
which have the mode cookie or specify the mode in file-local
variables, etc.  I don't see any problem with the user saying that the
symbol c-mode should be interpreted as meaning some other mode should
be invoked when normal-mode is called with that symbol as its first
argument.