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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 15 Nov 2024 13:04:25 +0000
> Cc: 74339@debbugs.gnu.org, monnier@iro.umontreal.ca, acm@muc.de
> From: Alan Mackenzie <acm@muc.de>
> 
> > The symmetry that I was talking about is in handling c-mode
> > specification in auto-mode-alist: it will either invoke c-mode or
> > c-ts-mode.
> 
> Excuse me, but that is NOT symmetry.  It is grossly assymetric.  If you
> weren't agreeing to symmetry why did you say you were?

It appears that we meant two different meanings of "symmetry" here.  I
was agreeing to the meaning I had in mind, which I explained above.

> > This is the issue at hand: to allow users to express their preferences
> > about c-mode in a way that is reversible.
> 
> See, it's starting already: the abuse of `c-mode' to mean "the current
> mode handling C" rather than "C Mode".  It is this dilution of CC Mode's
> trademarks which will be so damaging to CC Mode.  `c-mode' means C Mode,
> and must carry on meaning that.  Why did you use `c-mode' in that way?

We treat c-mode as a general indication that the file's contents is
written in C.  That is how major-mode-remap-* machinery treats a
mode's symbol.  Once we started supporting mode remapping, the literal
meaning of foo-mode to mean a single mode is no longer accurate,
because remapping might mean the actual mode that is turned on is a
different mode.

> You agreed, I think yesterday, that the solution we come up with will
> not damage CC Mode.  I would like to be sure that this is still the
> case.

I don't see any damage in what I propose.  Mode remapping doesn't
denigrate the remapped mode, it is just a vehicle for users to prefer
a different mode without a lot of customizations and changes to actual
files.  It is analogous to changing the attributes of a face: the face
is still called by the same name, but its attributes can be very
different.

> > The symmetry is in what cc-mode and c-ts-mode do with
> > major-mode-remap-defaults: each one of them removes the existing
> > elements that remap c-mode and adds its own elements which prefer
> > itself for C files.  IOW, the symmetry is in allowing users to prefer
> > c-mode or c-ts-mode as they wish, and allow them to change the
> > preference during a session with predictable results, regardless of
> > the preference: the preferred mode will be used after its file is
> > reloaded.
> 
> Yesterday, you made several decisions/concessions: your post at Thu, 14
> Nov 2024 18:59:53 +0200 read as follows:
> 
> #########################################################################
> > Date: Thu, 14 Nov 2024 16:20:37 +0000
> > Cc: 74339@debbugs.gnu.org, monnier@iro.umontreal.ca, acm@muc.de
> > From: Alan Mackenzie <acm@muc.de>
> >
> > > > 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.
> >
> > > That's what I suggested.  If you agree, let's make that change and
> > > move on.
> >
> > OK.  It would seem there is then no need to put entries for
> > c-mode/c-ts-mode into major-mode-remap-defaults.  I don't think this
> > solution is optimal, though.  Perhaps we can come up with something
> > better for Emacs 31.  But let's just go with this "last loaded wins"
> > strategem for Emacs 30.
> 
> OK, thanks.  So I guess you will soon make that change in cc-mode.el
> on the release branch?
> #########################################################################
> 
> As can be seen, you agreed to fix the bug by making entries in
> auto-mode-alist and not using major-mode-remap-defaults.  Less than 24
> hours later, you've changed your mind.  How am I meant to keep up with
> this form of discussion?

I've misread your proposal, sorry.  I didn't see the reference to
auto-mode-alist, only to major-mode-remap-defaults.  Avoiding adding
the c-mode entries to major-mode-remap-defaults is fine by me, if
c-mode will instead remove the entries put there by c-ts-mode.
(Although I think that it is better to add '(c-mode) after such
removal, for better reliability.)

> What changed between yesterday and today, that using auto-mode-alist is
> now no longer acceptable?

Nothing changed.  I never wanted to change auto-mode-alist, as that
would mean going back.  I simply missed your single reference to that,
sorry.

> I suggest again, that the use of auto-mode-alist in the way we agreed
> yesterday is the best way forward.  It is simple, well understood, and
> has been in use for, perhaps, 40 years.  It does not have the
> unpredictable effects that the use of major-mode-remap-defaults would
> have.  No substantial objections to this fix have been raised, beyond
> "it's new code late in a release cycle".
> 
> Whichever fix we use, there is going to be new code in the release
> branch.  In any of these fixes, the code is going to be simple, easily
> tested, and well understood.  So let's choose a fix for more substantial
> reasons.

The new code I have in mind (similar to what Stefan posted) is a
simple change of the current code, and affects the same variable.  The
suggestion to modify auto-mode-alist, by contrast, is a much more
significant change wrt what we have now.  So I prefer the former, at
least for the release branch.

> > There was never a feature in Emacs to invoke c-mode when a file
> > specifies c-ts-mode.  (There are also no files which specify c-ts-mode
> > in their file-local variables, and auto-mode-alist doesn't mention
> > c-ts-mode, so such a remapping has a largely academic value.)  The
> > current code in cc-mode.el, which adds elements to
> > major-mode-remap-defaults, doesn't remap c-ts-mode to c-mode, either.
> > So this interpretation of "symmetry" is a separate issue that should
> > be discussed separately, and we definitely don't want to add such
> > features to the release branch at this point, even if we agree to
> > having that in the future.
> 
> > (Stefan's thinking is that it's probably wrong to specify c-ts-mode in
> > in auto-mode-alist and in file-local variables anyway, although this
> > is still under discussion.
> 
> This is a critical point.  I don't know why Stefan thinks it would be
> wrong to use auto-mode-alist.  He hasn't said.

He did, in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=74339#77 :

> >> Not quite: `auto-mode-alist` should always map `.c` files to `c-mode`.
> > Why "always"?
> 
> Because the preference between `c-mode` and `c-ts-mode` should apply not
> only to those files whose mode is decided by `auto-mode-alist` but also
> to those where this is decided via other means such as via a file-local
> `mode` setting, or via `magic-mode-alist`, or ...

> > If we agree to that, it would mean that specifying c-mode in
> > auto-mode-alist and -* c -*- cookies in a file does not necessarily
> > mean to invoke c-mode literally, but instead to invoke the mode in
> > which the user wants to visit C files, i.e. a mode that is subject to
> > user options.
> 
> How then would it be possible to specify C Mode in auto-mode-alist?
> It wouldn't.

If the user prefers to use c-ts-mode, Emacs should honor that.  Users
who want to use c-mode are supported by default, and don't need to do
anything.  Thus, it is already possible to specify C Mode in
auto-mode-alist: that's the only mode mentioned there for C files.  So
I don't quite understand your question: it is already possible to
specify C Mode, and we are actually doing that by default.

> My proposal yesterday of using `current-c-mode' would solve
> this problem neatly - the user would be able to enter any of
> `current-c-mode', `c-ts-mode', or `c-mode' to express her meaning
> precisely.

This can be discussed for master, but it is not appropriate for the
release branch, for the reasons I explained already.