bug#74339: 30.0.92; CC Mode stomps C TS Mode

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 13 Nov 2024 18:58:01 +0000
> Cc: 74339@debbugs.gnu.org, acm@muc.de
> From: Alan Mackenzie <acm@muc.de>
> 
> >     As regards which mode normal-mode calls for the symbols c-mode,
> >     etc., the first of the following which applies holds:
> >     (i) If the user has made a pertinent entry in
> >     major-mode-remap-alist, this is used.
> >     (ii) If CC Mode has been loaded, c-mode is called.
> >     (iii) If library c-ts-mode has been loaded, c-ts-mode is
> >     called.
> >     (iv) Otherwise c-mode is called.
> 
> >     * lisp/progmodes/cc-mode.el (top level): Add entries to
> >     major-mode-remap-defaults to implement the above.
> 
> When I installed that patch, it was because c-ts-mode was stomping all
> over C Mode.

c-ts-mode was not stomping over anything.  When the user expresses her
desire to use c-ts-mode, Emacs arranges for C files to use c-ts-mode.
That's what users expect from Emacs when they express their
preferences.

> I expected there to have been some negative feedback about
> my patch, and was somewhat surprised that it was apparently accepted.

You have never explained the actual effect of your changes: that once
CC Mode is loaded once, there's no way for the user to have c-ts-mode
used for visiting C/C++ files, except by manually turning on c-ts-mode
in each and every buffer, after the file is visited.  Does that sound
to you as reasonable behavior?  That's what this bug is about.

> > I don't quite understand the rationale (and even less the
> > implementation), and don't recall any discussions of this; ....
> 
> The rationale was to protect the symbol `c-mode' (and friends) from
> being misused to mean c-ts-mode, etc.

The symbol was not misused.  The implementation of the user's
preference to use c-ts-mode was via major-mode remapping, that's all.
Why you take that personally is beyond me.  Don't you agree that when
the user wants to use c-ts-mode, Emacs needs to obey?  Well, currently
it doesn't!  Are you really okay with that??

> I believe that at the beginning of development of the tree-sitter
> modes, there was an agreement, or at least an understanding, that
> the new modes would not usurp the names of the existing modes.  The
> mechanism of major-mode-remap-defaults violates that understanding.

No, it doesn't.  It uses remapping, that's all, and it does that only
if the user says-so.  Why is that a problem?  More importantly, why
the "solution" is to completely subvert user settings??

> I'm not aware of the discussions which led to the
> major-mode-remap-defaults mechanism, even having searched for them, and
> I was unaware they were taking place.  I certainly wasn't invited to
> participate, despite the fact that CC Mode was central to the problem
> being discussed.

This is immaterial to the subject of this bug report.  This bug report
is not about the lack of discussion, it is about the current behavior
of Emacs 30 which IMNSHO is simply unacceptable.  There's no precedent
to Emacs ignoring user preferences.  I'm surprised you are arguing for
this buggy behavior, instead of discussing how to fix it, and fix it
soon.  Because we cannot possibly release Emacs 30 with this bug.

> >>>> Anyhow, I see a way forward.  I will amend CC Mode also to make
> >>>> entries in major-mode-remap-defaults.  This would appear to be in
> >>>> the spirit of that undocumented variable.  It doesn't feel ideal,
> >>>> though.

And you consider that sufficient to expect any meaningful response?
You haven't even hinted on what the solution will do, and certainly
didn't say that it would mean users will be _unable_ to make c-ts-mode
their preferred mode for C/C++ files.  Did you really mean that to be
the result of your changes?

> I did indeed amend CC Mode as I suggested, and that was the patch
> currently under discussion.  It is indeed not ideal.

It isn't "not ideal", it is simply buggy!  We cannot possibly ignore
user preferences in this way.  Users are used to load c-ts-mode and
expect that all the C/C++ files after that are visited using that
mode.  Now this expression of user preferences is completely ignored!

> Having looked at it in detail in the summer, I'm afraid the bug is
> anything but simple.  For example, M-x revert-buffer has the habit of
> silently changing C Mode into c-ts-mode, or vice versa.

If the user prefers to use c-ts-mode, then revert-buffer _should_ use
c-ts-mode, not c-mode.  The same happens if you change the way
normal-mode determines the mode and then revert the buffer.  This
change in what revert-buffer does is now another user expectation your
change has broken, and it, too, must be fixed.

> I did some work privately on this problem some months ago, coming up
> with a solution where revert-buffer worked properly, -*- c -*- worked
> properly, and the major mode chosen for a file was controlled solely by
> auto-mode-alist (and maybe major-mode-remap-alist).  Some of that work
> might now be relevant.

I'm not interested in having revert-buffer ignore user preferences of
using c-ts-mode, and I'm not interested in having the -*- c -*- cookie
invoke c-mode when the user prefers c-ts-mode.  So any changes in that
direction are not welcome.

> > If the above is not a bug, but the intended (by you, Alan) behavior,
> > then we need to talk about changing it, because this is not how user
> > preferences in this regard are supposed to be heeded by Emacs.
> 
> I'm not unhappy about the need for change, and as I said, I was
> expecting such feedback back in May.  It didn't come then.

What happened in May is besides the point now, but you cannot expect
any meaningful responses if you don't describe the solution.  And if
you thought the solution you were about to install could be
controversial, you should have triggered the discussion yourself, by
pointing the aspects which could be controversial.  That would have
been responsible behavior of a mode maintainer.

But all this is water under the bridge now.  The only thing I'm
interested in is how to fix this bad breakage, and how to fix it fast.
Because Emacs 30 is in the last stages of pretest, and I don't want to
delay the release.

> As for changing things, I insist as strongly as I'm allowed to on this
> mailing list that the symbols `c-mode' and `c++-mode' are essential
> properties of CC Mode, belong to CC Mode, and must not be stolen and
> misused in any way to mean `c-ts-mode' and `c++-ts-mode'; unless the
> user so decides and makes such a setting in major-mode-remap-alist.

Sorry, I disagree (and find your insistence unreasonable).  Please
drop these arguments, they are not going to lead to anything
constructive.

> > The expected behavior is: as soon as the user loads c-ts-mode, all the
> > subsequent C/C++ files are visited using C/C++ TS Mode.  To revert
> > back to CC Mode, the user must load cc-mode again.
> 
> I don't think that reloading worked when I tried it, though that was
> some while ago.  I think newly visited C files just went into c-ts-mode
> regardless.  Amending Emacs to behave like this on loading a library
> might be a good way to fix the current problem.

If we can fix Emacs to behave like I described, i.e. return to the
state where C/C++ files are visited in cc-mode rather than in
c-ts-mode, just by reloading cc-mode, would you agree with such a fix?

If yes, please start by explaining why you chose to modify
major-mode-remap-defaults to have this form, after cc-mode is loaded:

   ((c-or-c++-mode) (c++-mode) (c-mode) (c-or-c++-mode . c-or-c++-ts-mode) (c-mode . c-ts-mode) (c++-mode . c++-ts-mode) (LaTeX-mode . latex-mode) (plain-TeX-mode . plain-tex-mode) (TeX-mode . tex-mode))

Why do you need those (c-or-c++-mode) (c++-mode) (c-mode) entries
there, and why did you not remove the elements which remap to
c-ts-mode instead?  The root cause of the bug is that the original
remapping entries are left in the list, and so add-to-list does
nothing.  If this is on purpose, and not a simple thinko, then you
have a lot of explaining to do.