Re: Subversion of user chosen major mode by Emacs. [Was: My usage of imenu is broken.]

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 29 May 2024 11:16:44 +0000
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > In the past, `auto-mode-alist` way used for that, but that did not
> > account for cases where the major mode is not specified via the file
> > name, but instead via `-*- mode -*-`, or via `interpreter-mode-alist`,
> > or via ...
> 
> That's a case of going for 100% perfection at the expense of the normal
> case.  People don't put -*- c-mode -*- into files.  Not as a general
> rule.
> 
> c-mode and c++-mode are registered trade marks of CC Mode, much as Emacs
> means GNU Emacs, not any other editor with similar functionality.  If
> somebody has specified -*- c-mode -*-, then they mean CC Mode.

Actually, this may or may not be true.  There are cases where people
put "-*- c++ -*-" etc. in files, but any mode supporting C++ will do.
As one example, consider the libstdc++ headers such as 'algorithm' and
others that have no file-name extension: it is clear that the mode
cookie there does not necessarily mean these files should only be
edited with c++-mode.  As another example, consider the *.h files that
are part of GDB sources: not every header file there will be
identified by Emacs as C++ just by looking at the contents, so the GDB
developers want to make sure Emacs turns on some C++ supporting mode
when editing these files.

As yet another example, consider our .dir-locals.el files: the
mode-specific settings there don't care whether the user uses c-mode
or c-ts-mode to edit our C sources.

And there can be other examples.  So sometimes the major mode symbol
does in fact stand for the type of content and not for the specific
mode it names.  And Emacs should support these use cases, because
users are rightfully annoyed when they need to duplicate the same
boring settings.

> or Emacs should provide something like -*- c-generic-mode -*-.

That'd be swell, and we do provide these in some cases.  But doing so
is only possible if the maintainers of the related modes agree to
cooperate to bring their modes closer.  And you at the time were not
very enthusiastic, to say the least, about any such involvement.  So
here we are.

> > Also it encouraged `c-ts-mode.el` (and friends) duplicating
> > the regexps used to specify "this is probably a C file", often doing it
> > slightly differently from the other major mode.
> 
> Surely a trivial problem, if a problem at all.

Actually, our experience since introduction of the *-ts-modes
indicates it is not a trivial problem at all.  To wit: we don't yet
have a good solution for it, and several naïve attempts proved to
cause problems we needed to fix.  It is surprising how a typical
mode's simplest definitions are tightly coupled with the
implementation of the basic features we need for major modes:
font-lock, indentation, syntax analysis, etc.  It turns out our
abstractions in that department leak like hell.

> > Instead, conceptually `auto-mode-alist` should now be used to specify
> > the type of content (tho represented not as something like a MIME type
> > but as a symbol that (usually) denotes a major mode), and then
> > `major-mode-remap` is used to decide which major mode to use for that
> > file type.
> 
> Oh deity, no!  auto-mode-alist specifies the MODE, not some abstract
> "content type".

See above: not necessarily true, at least not in all cases.

And note that mode symbols are used not only in auto-mode-alist.  A
very frequent use is as an argument to the likes of derived-mode-p.