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

[Alan Mackenzie]

Hello, Eli.

On Wed, Nov 13, 2024 at 16:00:58 +0200, Eli Zaretskii wrote:
> To reproduce:

>   emacs -Q
>   M-x load-library RET c-ts-mode RET
>   C-x C-f src/buffer.c
>   M-: major-mode RET
>    => c-ts-mode

> So far, so good: the user loads c-ts-mode, which means she prefers
> C/C++ TS Mode for C and C++ files, so visiting a C file turns on
> c-ts-mode instead of the default CC Mode.

> But:

>   emacs -Q
>   C-x C-f src/dispnew.c RET
>   M-x load-library RET c-ts-mode RET
>   C-x C-f src/buffer.c
>   M-: major-mode RET
>    => c-mode

> This is unexpected.  It means that if even a single file loads CC
> Mode, the user's preference of using C TS Mode is effectively ignored.

[ .... ]

> The above snippet from cc-mode.el was installed this last May, with
> the following log message:

>     In normal-mode, make c-mode call c-mode when CC Mode is loaded

>     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.  I expected there to have been some negative feedback about
my patch, and was somewhat surprised that it was apparently accepted.

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

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.

There _was_ discussion of the problem leading to the patch, in
particular, starting from this post in emacs-devel:

Date: Wed, 29 May 2024 11:16:44 +0000
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
Subject: Subversion of user chosen major mode by Emacs. [Was: My usage of imenu 
is broken.]

..  My final post in that thread, which nobody replied to, was:

Date: Thu, 30 May 2024 11:02:13 +0000
To: Eli Zaretskii <eliz@gnu.org>
Cc: acorallo@gnu.org, dmitry@gutov.dev, monnier@iro.umontreal.ca, 
emacs-devel@gnu.org

, in which my last paragraph was

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

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

> .... there's also no bug number for it.  But clearly the result is not
> acceptable, and I very much hope that there's some simple bug here
> that can be fixed real soon.

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.

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.

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

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.

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

> In GNU Emacs 30.0.92 (build 21, i686-pc-mingw32) of 2024-11-11 built on
>  ELIZ-PC
> Windowing system distributor 'Microsoft Corp.', version 10.0.22631
> System Description: Microsoft Windows 10 Enterprise (v10.0.2009.22631.4460)

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).