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

[Alan Mackenzie <acm@muc.de>]

Hello, Stefan.

On Tue, May 28, 2024 at 17:55:28 -0400, Stefan Monnier wrote:
> > I now understand what's happening.  Stefan M committed a patch some
> > while ago, the effect of which is to force users who've set up their
> > auto-mode-alist for CC Mode to use c-ts-mode, etc., instead.

> That's one way to see it.  🙂



> > Yesterday, I'd reverted src/eval.c (which normally gets loaded via
> > desktop), and Stefan's patch converted it to c-ts-mode without me being
> > aware of this.

> The way I see it, the problem is in `c-ts-mode.el` where merely loading
> the file changes the default mode to use for C files to `c-ts-mode`
> (tho only in the current session, thank god).

What's wrong with that?  "Merely" loading CC Mode adds entries to
auto-mode-alist for this.  Surely lots of other libraries do this, too.

> My patch(es) only change(s) the mechanism used for that.

No.  It/they subvert(s) the mode chosen by the user.  As I said, when I
did M-x revert-buffer yesterday, Emacs changed my major mode from C Mode
to c-ts-mode.  This is clearly unacceptable.

It is unacceptable to subvert the major mode set up by the user to some
other mode.  This is exactly what major-mode-remap-defaults is designed
to do.  If a user wishes to make such a substition that is her good
right, but for the Emacs maintainers silently to impose such a
substition on users is something else entirely.

> I think this is a misfeature of `c-ts-mode.el`, but this was the result
> of a long discussion and I don't think we want to revisit that yet.

Why did nobody involve me in this discussion, considering that the
result involves "stealing" CC Mode users?

> > I don't understand what major-mode-remap and major-mode-remap-defaults
> > are for.

> They are designed to allow specifying which C mode Emacs should use
> (not only for C, obviously).

That is what auto-mode-alist is for.  These two new alists do not add
useful functionality, they just add complexity, and they confuse users.

> 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.  If they
don't, they should write -*- c-ts-mode -*- instead, or Emacs should
provide something like -*- c-generic-mode -*-.

> 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.

> 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".  You're proposing duplicating the entries in
auto-mode-alist with another list of the same size.  This can only cause
user confusion when instead of pushing an element to a-m-a, they also
have to push one to m-m-remap, and make sure they match up.

The solution to this problem is to emphasise that auto-mode-alist is an
alist of filenames and major modes, like it always has been.

> > They would appear to be duplicating and confusing the mechanism
> > of auto-mode-alist, and seem unnecessary.  It seems clear they are too
> > difficult to use.

> Clear as mud, indeed.

Then lets sort this out.  How about you proposing a solution to M-x
revert-buffer changing a buffer's major mode?  My solution would be to
revert the patch that introduced major-mode-remap-defaults.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).