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

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Wed, Nov 13, 2024 at 22:13:02 +0200, Eli Zaretskii wrote:
> > 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.

It was.

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

Yes, and if the said user wants to go back to C Mode, she should be able
to.  Before my patch this was difficult.  Anybody wishing to use
c-ts-mode can use it, by use of the symbol `c-ts-mode'.

> > 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 put in the commit message precisely how it would behave.  Admittedly,
the restriction to 63 character lines made it a little less clear, but
the full description was there.

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

The user expressing preference by setting major-mode-remap-alists was
unaffected by my patch.

> Why you take that personally is beyond me.

Perhaps because I've been working over 20 years on CC Mode, care about
it, and am loathe to see it consigned to oblivion by the surreptitious
diversion of its users to c-ts-mode, etc.  You would take it personally
if somebody started using "Eli Zaretskii" to refer to some other Emacs
maintainer.  If you want to kill off CC Mode, then change the symbols
`c-mode' and `c++-mode' to mean something else, so that its users can't
find the modes they want.

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

When the user wants c-ts-mode she should be able to use the symbol
`c-ts-mode', somehow.  Likewise for C Mode and `c-mode'.  If some user
adds an entry to auto-mode-alist with `c-mode' in its cdr, do you really
think it correct to start c-ts-mode?  Because that was the state of Emacs
-Q before my patch.  Don't you agree something needs to be fixed, there?

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

"Remapping" is a euphemism for stealing.  And it is done not by the user
but by the maintainer of c-ts-mode.el, who decided to "remap" `c-mode'
away from C Mode and onto c-ts-mode.

> Why is that a problem?  More importantly, why the "solution" is to
> completely subvert user settings??

It's a problem because it prevents CC Mode users from easily finding
their preferred modes.  The "solution" (my patch) didn't touch user
settings.  It altered default settings only.

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

It's the main reason the bug happened.

> This bug report is not about the lack of discussion, it is about the
> current behavior of Emacs 30 which IMNSHO is simply unacceptable.

I'm not arguing with that.

> There's no precedent to Emacs ignoring user preferences.

I think that's perhaps being a touch optimistic.  Diverting C Mode into
c-ts-mode is ignoring user preferences.  We shouldn't do it.

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

I've made quite a few suggestions about a fix.

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

Actually, yes.  I'm only surprised it took nearly 6 months.

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

I described my patch in the customary detail in its commit message,
giving a complete rundown of its mechanism.

> Did you really mean that to be the result of your changes?

No, I intended to spark some discussion about the faults in the then
current implementation, namely that it would steal users away from CC
Mode.

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

Can I take it that you will respect the choice of users who wish to
remain on CC Mode as much as those who wish the new tree-sitter modes?

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

And if a user has made no such choice, normal-mode will forcibly change
the major modes of their buffers, whether they like it or not.  As I said
earlier, I have a fix for this which I have not pushed to Savannah.

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

Instead Emacs ignores the perfectly reasonable preference to have
buffers modes stay the same as when the user set them.

> .... and I'm not interested in having the -*- c -*- cookie invoke
> c-mode when the user prefers c-ts-mode.

My fix here was having the cookie invoke the user's preferred 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, ....

A large part of your recent posts has been about criticising me.  What
happened in May and before is the reason for this bug report.  I
certainly intend to learn from it.

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

Again, if the controversial aspects of the major-mode-default-alist plan
hadn't been witheld from me, I would perhaps have been able to contribute
to a solution in a more reasonable fashion.

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

You've read my protests about how Emacs was before my patch.  I ask for
the fix not to disadvantage CC Mode again the way it was, and if possible
to respect CC Mode's ownership of the pertinent symbols.

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

I think so, provided there was symmetry between the tree-sitter modes and
CC Mode.  I would suggest the obvious fix; loading either one of the
libraries should append its entries to auto-mode-alist, having removed
any "lower down" entries.

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

Of course it was on purpose.  I wanted to provoke discussion and
argument, with the aim of getting a solution which would be fair to CC
Mode, as well as to c-ts-mode.  The previous state of the code was
grossly unfair.  Again, if I had been involved in the original
discussions, none of this would have happened.

-- 
Alan Mackenzie (Nuremberg, Germany).