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

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Fri, Nov 15, 2024 at 16:43:28 +0200, Eli Zaretskii wrote:
> > 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.

One can write, in the Local Variables: section

    mode: c-ts

..  This will cause the buffer to start in c-ts-mode regardless of any
other current settings.  As from Emacs 30, you are proposing that there
be no analogous setting for c-mode.  Up to now, one has been able to
write:

    mode: c

..  When that line is followed by setting other CC Mode variables (as is
surely common for any such use of the major mode setting) that will
signal some sort of error on opening the buffer, should c-mode have been
"remapped" to c-ts-mode.  Or if it doesn't do that, those local variables
will be disregarded.  This is a Bad Thing.

This symmetry between c-ts-mode and c-mode should be preserved.

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

When did this come up for discussion?  I surely wasn't involved in any
such discussion, and such a massive, far reaching change definitely ought
to have been discussed.  The consequence of that is that there is now no
way unambiguously to refer to c-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.

See my example above for an example of damage.  The very fact that should
this change go ahead, there will be no way for a user to specify c-mode
unambiguously is damage.  It hollows out the very substance of CC Mode,
namely it's names.

> 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 face's functionality remains unchanged.  "Remapping" mode names
changes the functionality substantially.

[ .... ]

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

That's not what I meant by "avoiding adding the c-mode entries to
major-mode-remap-defaults".  What I meant was avoiding adding the c-mode
entries to major-mod-remap-defaults.  In particular by other modes which
have no business messing with CC Mode's symbols.

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

So, it would appear the agreement we came to yesterday evening was
totally illusory.  There was no agreement.

Neither of the two criteria we agreed upon look like they will be
respected:
(i) Symmetry between c-mode and c-ts-mode;
(ii) No damage to CC Mode in the change;

I don't see what you mean by "that would mean going back", or what would
be bad about that; new doesn't always mean better.  What's wrong with
using auto-mode-alist for this purpose?  It lacks the disadvantages of
major-mode-remap-defaults, and I don't see what disadvantages it has
itself.  Can't we at least use it for Emacs 30, so that we have the
opportunity (which there hasn't been up till now) to discuss the
"remapping" without the pressure of an impending release?

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

The change to use auto-mode-alist would be minimal, and well within the
scope of simple code review and testing.  We are only discussing the
release branch here; the damage done to CC Mode by the "remapping" of its
symbols in Emacs 30, should it be implemented, namely loss of users, will
be permanent, and not recoverable in future Emacs versions.  Let's get it
right, now.

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

OK, thanks.  He is proposing that the meaning of -*- c -*-, `c-mode' as
used in normal-mode, etc., should, from the user's point of view, be
changed in an opt-out fashion.  He is proposing that there be no way to
specify C Mode in a local variables section.  Such changes should be
opt-in, not opt-out.  They would certainly need an entry in NEWS. if
there's not already one there.

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

If the user expresses a preference for C Mode using "mode: c" in the
Local Variables: section, that should be respected, too.

c-ts-mode can be loaded without any preference being expressed by the
user.  M-x c-ts-mode does not necessarily mean the user prefers that
mode, or wants "remapping"; she could equally well be just trying out the
new mode.

We should perhaps provide users with a means explicitly to express such a
preference.

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

That only applies to users using only CC Mode.  Any deviation from this
stricture (e.g., by having a c-ts-mode buffer in a desktop file) will
break it.

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

It is only the release branch, not master, which is going to damage CC
Mode.  We need to sort out these issues now.  Why weren't they
discussed long ago?

-- 
Alan Mackenzie (Nuremberg, Germany).