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

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

[Eli Zaretskii]

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.

This seems to happen due to this code in cc-mode.el:

  ;; Make entries in `major-mode-remap-defaults' to ensure that when CC
  ;; Mode has been loaded, the symbols `c-mode' etc., will call CC Mode's
  ;; modes rather than c-ts-mode etc..
  (when (boundp 'major-mode-remap-defaults)
    (add-to-list 'major-mode-remap-defaults '(c++-mode . c++-ts-mode))
    (add-to-list 'major-mode-remap-defaults '(c-mode . c-ts-mode))
    (add-to-list 'major-mode-remap-defaults '(c-or-c++-mode . c-or-c++-ts-mode))
    (let (entry)
      (dolist (mode '(c-mode c++-mode c-or-c++-mode))
	(if (and (setq entry (assq mode major-mode-remap-defaults))
		 (null (cdr entry)))
	    (setq major-mode-remap-defaults
		  (delq entry major-mode-remap-defaults)))
	(push (cons mode nil) major-mode-remap-defaults))))

Here's what major-mode-remap-defaults looks like when I load c-ts-mode
into "emacs -Q":

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

And here's how it looks if I first visit a C file (which loads
cc-mode):

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

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.

I don't quite understand the rationale (and even less the
implementation), and don't recall any discussions of this; 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.  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.

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.

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)

Configured using:
 'configure -C --prefix=/d/usr --with-wide-int
 --enable-checking=yes,glyphs --without-native-compilation 'CFLAGS=-O0
 -gdwarf-4 -g3''

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG LCMS2 LIBXML2 MODULES NOTIFY W32NOTIFY
PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS
TREE_SITTER WEBP XPM ZLIB

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1252

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date subr-x mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
c++-ts-mode c-ts-mode c-ts-common treesit cl-loaddefs cl-lib thingatpt
find-func rmc iso-transl tooltip cconv eldoc paren electric uniquify
ediff-hook vc-hooks lisp-float-type elisp-mode mwheel touch-screen
dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq
simple cl-generic indonesian philippine cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button
loaddefs theme-loaddefs faces cus-face macroexp files window
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget keymap hashtable-print-readable backquote threads
w32notify w32 lcms2 multi-tty move-toolbar make-network-process emacs)

Memory information:
((conses 16 49304 16294) (symbols 48 6997 0) (strings 16 17805 2859)
 (string-bytes 1 375146) (vectors 16 10077)
 (vector-slots 8 114927 6271) (floats 8 25 6) (intervals 40 301 140)
 (buffers 896 10))

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

[Eli Zaretskii]

> Cc: Alan Mackenzie <acm@muc.de>
> Date: Wed, 13 Nov 2024 16:00:58 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> 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.
> 
> This seems to happen due to this code in cc-mode.el:
> 
>   ;; Make entries in `major-mode-remap-defaults' to ensure that when CC
>   ;; Mode has been loaded, the symbols `c-mode' etc., will call CC Mode's
>   ;; modes rather than c-ts-mode etc..
>   (when (boundp 'major-mode-remap-defaults)
>     (add-to-list 'major-mode-remap-defaults '(c++-mode . c++-ts-mode))
>     (add-to-list 'major-mode-remap-defaults '(c-mode . c-ts-mode))
>     (add-to-list 'major-mode-remap-defaults '(c-or-c++-mode . c-or-c++-ts-mode))
>     (let (entry)
>       (dolist (mode '(c-mode c++-mode c-or-c++-mode))
> 	(if (and (setq entry (assq mode major-mode-remap-defaults))
> 		 (null (cdr entry)))
> 	    (setq major-mode-remap-defaults
> 		  (delq entry major-mode-remap-defaults)))
> 	(push (cons mode nil) major-mode-remap-defaults))))
> 
> Here's what major-mode-remap-defaults looks like when I load c-ts-mode
> into "emacs -Q":
> 
>   ((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))
> 
> And here's how it looks if I first visit a C file (which loads
> cc-mode):
> 
>   ((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))
> 
> 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.
> 
> I don't quite understand the rationale (and even less the
> implementation), and don't recall any discussions of this; 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.  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.
> 
> 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.

And adding Stefan to the discussion, since he wrote the
major-mode-remap-defaults stuff in c-ts-mode.el.

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

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

[Eli Zaretskii]

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

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> This seems to happen due to this code in cc-mode.el:
>
>   ;; Make entries in `major-mode-remap-defaults' to ensure that when CC
>   ;; Mode has been loaded, the symbols `c-mode' etc., will call CC Mode's
>   ;; modes rather than c-ts-mode etc..
>   (when (boundp 'major-mode-remap-defaults)
>     (add-to-list 'major-mode-remap-defaults '(c++-mode . c++-ts-mode))
>     (add-to-list 'major-mode-remap-defaults '(c-mode . c-ts-mode))
>     (add-to-list 'major-mode-remap-defaults '(c-or-c++-mode . c-or-c++-ts-mode))
>     (let (entry)
>       (dolist (mode '(c-mode c++-mode c-or-c++-mode))
> 	(if (and (setq entry (assq mode major-mode-remap-defaults))
> 		 (null (cdr entry)))
> 	    (setq major-mode-remap-defaults
> 		  (delq entry major-mode-remap-defaults)))
> 	(push (cons mode nil) major-mode-remap-defaults))))

Interesting!

I hadn't actually looked at that code.

AFAICT it's the result of the decision to make `c-ts-mode.el` add itself
to `major-mode-remap-defaults` when the file is loaded (which AFAIK we
don't want to re-discuss).  To defend against the case where that file
was loaded without the intention to use c-ts-mode everywhere the above
code "one ups" `c-ts-mode.el`s settings so as to take precedence
over them.

Looks like an arms race to me.  🙂

I think a "more fair" solution would be to do something like:

    ;; Make entries in `major-mode-remap-defaults' to ensure that when CC
    ;; Mode has been loaded, the symbols `c-mode' etc., will call CC Mode's
    ;; modes rather than c-ts-mode etc..
    (when (boundp 'major-mode-remap-defaults)
      (dolist (mode '(c-mode c++-mode c-or-c++-mode))
        (let ((entry (assq mode major-mode-remap-defaults)))
          (when entry
            (setq major-mode-remap-defaults
                  (delq entry major-mode-remap-defaults))))))

The idea being that whichever file was loaded last (`c-mode.el` or
`c-ts-mode.el`) would take precedence.

Personally, my vote is for neither file to touch that
`major-mode-remap-defaults` variable when it is loaded.
Instead, they each could emit a message encouraging the user to
customize `major-mode-remap-alist`.
Maybe they could do that only when they see that the "other" file/mode
is also loaded (i.e. only once we have evidence that there is
a conflict).


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 74339@debbugs.gnu.org,  Alan Mackenzie <acm@muc.de>
> Date: Wed, 13 Nov 2024 15:28:08 -0500
> 
> I hadn't actually looked at that code.
> 
> AFAICT it's the result of the decision to make `c-ts-mode.el` add itself
> to `major-mode-remap-defaults` when the file is loaded (which AFAIK we
> don't want to re-discuss).  To defend against the case where that file
> was loaded without the intention to use c-ts-mode everywhere the above
> code "one ups" `c-ts-mode.el`s settings so as to take precedence
> over them.
> 
> Looks like an arms race to me.  🙂

Not a race, more like a knockout: once cc-mode is loaded, the race is
over.

> I think a "more fair" solution would be to do something like:
> 
>     ;; Make entries in `major-mode-remap-defaults' to ensure that when CC
>     ;; Mode has been loaded, the symbols `c-mode' etc., will call CC Mode's
>     ;; modes rather than c-ts-mode etc..
>     (when (boundp 'major-mode-remap-defaults)
>       (dolist (mode '(c-mode c++-mode c-or-c++-mode))
>         (let ((entry (assq mode major-mode-remap-defaults)))
>           (when entry
>             (setq major-mode-remap-defaults
>                   (delq entry major-mode-remap-defaults))))))
> 
> The idea being that whichever file was loaded last (`c-mode.el` or
> `c-ts-mode.el`) would take precedence.

Yes, that's what I was suggesting.  I don't understand why this was
not done to begin with, except if the current code was a thinko.

> Personally, my vote is for neither file to touch that
> `major-mode-remap-defaults` variable when it is loaded.
> Instead, they each could emit a message encouraging the user to
> customize `major-mode-remap-alist`.
> Maybe they could do that only when they see that the "other" file/mode
> is also loaded (i.e. only once we have evidence that there is
> a conflict).

We can try other methods on master (and there's actually a discussion
there about this).  But on the release branch we cannot make such
changes, we must instead fix this stuff so that, from the user
perspective, Emacs 30 works the same as Emacs 29: if the user loads
c-ts-mode, C/C++ files are visited in c-ts-mode, until cc-mode is
re-loaded.

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> AFAICT it's the result of the decision to make `c-ts-mode.el` add itself
>> to `major-mode-remap-defaults` when the file is loaded (which AFAIK we
>> don't want to re-discuss).  To defend against the case where that file
>> was loaded without the intention to use c-ts-mode everywhere the above
>> code "one ups" `c-ts-mode.el`s settings so as to take precedence
>> over them.
>> 
>> Looks like an arms race to me.  🙂
>
> Not a race, more like a knockout: once cc-mode is loaded, the race is
> over.

That's because you haven't seen the coming patch to `c-ts-mode.el` which
removes the `cc-mode.el` entries, after which `cc-mode.el` will
use another, yet sophisticated approach, etc...


        Stefan

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

[Alan Mackenzie]

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

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

It was (and still is) a small matter of configuring `major-mode-remap-alist`.

> Anybody wishing to use c-ts-mode can use it, by use of the symbol
> `c-ts-mode'.

In order to work on all C files, this is done by ... configuring
`major-mode-remap-alist`.

Not sure why you say one of them is "difficult" but not the other.

>> 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-alist was
> unaffected by my patch.

Indeed, and I think we should help the users add such a setting rather
than have them depend on unreliable defaults which depend on which file
is loaded or not or when.

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

Really?  I find that hard to believe when reading the code.
AFAICT, in `emacs -Q` `major-mode-remap-defaults` is:

    ((LaTeX-mode . latex-mode) (plain-TeX-mode . plain-tex-mode)
     (TeX-mode . tex-mode))

and `auto-mode-alist` maps `.c` files to `c-mode` so I can't see how and
why a C file would be put into `c-ts-mode` without some explicit action
on the part of the user.

> Don't you agree something needs to be fixed, there?

I agree what you describe would be a bug, but I think there's something
missing in your description.

[ Sorry, that's all for now, I didn't have time yet to finish your message.  ]


        Stefan

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

[Eli Zaretskii]

> Date: Wed, 13 Nov 2024 22:34:19 +0000
> Cc: 74339@debbugs.gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>,
>   acm@muc.de
> From: Alan Mackenzie <acm@muc.de>
> 
> > > 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?

Of course!  That's what happens by default if the user didn't load
c-ts-mode, and (under my suggested idea of a change) will happen if
the user loads cc-mode after loading c-ts-mode.  IOW, the last mode
loaded will "win".

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

No, it won't.  This could happen only if the user loads c-ts-mode
in-between, which means the user prefers c-ts-mode.  Without that,
normal-mode will always revert to c-mode in the default Emacs
configuration.

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

Reverting the buffer activates whatever major mode corresponds to the
file name and other relevant settings at the moment of the reverting.
If you modify those settings in-between, it is quite possible (and
expected!) that normal-mode will activate a different mode.  This is
how Emacs always behaved (and should keep behaving).  Anything else is
against user expectations.

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

That's what I suggested.  If you agree, let's make that change and
move on.

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

[Dmitry Gutov]

On 14/11/2024 08:59, Eli Zaretskii wrote:
>> 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?
> Of course!  That's what happens by default if the user didn't load
> c-ts-mode, and (under my suggested idea of a change) will happen if
> the user loads cc-mode after loading c-ts-mode.  IOW, the last mode
> loaded will "win".

JFYI, 'M-x js-ts-mode' loads cc-mode.

>> 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.
> No, it won't.  This could happen only if the user loads c-ts-mode
> in-between, which means the user prefers c-ts-mode.  Without that,
> normal-mode will always revert to c-mode in the default Emacs
> configuration.

I'm personally skeptical that loading a package (or invoking a mode) 
indicates a strong user preference, but ok, let's call it that.

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

[Eli Zaretskii]

> Date: Thu, 14 Nov 2024 11:24:32 +0200
> Cc: monnier@iro.umontreal.ca, 74339@debbugs.gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 14/11/2024 08:59, Eli Zaretskii wrote:
> >> 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?
> > Of course!  That's what happens by default if the user didn't load
> > c-ts-mode, and (under my suggested idea of a change) will happen if
> > the user loads cc-mode after loading c-ts-mode.  IOW, the last mode
> > loaded will "win".
> 
> JFYI, 'M-x js-ts-mode' loads cc-mode.

That's because js.el does that.  This was so in Emacs 29 already.  And
there are other packages that do the same:

  $ fgrep -R "(require 'cc-mode)" ../lisp --include="*.el"
  ../lisp/generic-x.el:1275:(require 'cc-mode)
  ../lisp/org/ob-C.el:39:(require 'cc-mode)
  ../lisp/org/ob-fortran.el:36:(require 'cc-mode)
  ../lisp/progmodes/antlr-mode.el:84:(require 'cc-mode)
  ../lisp/progmodes/cmacexp.el:91:(require 'cc-mode)
  ../lisp/progmodes/csharp-mode.el:34:(require 'cc-mode)
  ../lisp/progmodes/cwarn.el:107:(require 'cc-mode)
  ../lisp/progmodes/hideif.el:120:(require 'cc-mode)
  ../lisp/progmodes/js.el:48:(require 'cc-mode)

I guess users who use these features and want to use c-ts-mode as
their C major mode will need to use with-eval-after-load to restore
the preferences after loading one of these packages (or customize
major-mode-remap-alist).  Ugh!

> >> 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.
> > No, it won't.  This could happen only if the user loads c-ts-mode
> > in-between, which means the user prefers c-ts-mode.  Without that,
> > normal-mode will always revert to c-mode in the default Emacs
> > configuration.
> 
> I'm personally skeptical that loading a package (or invoking a mode) 
> indicates a strong user preference, but ok, let's call it that.

We can change this in Emacs 31, but it's too late for Emacs 30.

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> I'm personally skeptical that loading a package (or invoking a mode)
> indicates a strong user preference, but ok, let's call it that.

Indeed, I think loading a package does not show a strong user
preference.  As we've seen, it can happen "by accident" in various
circumstances that are only loosely related to using the code in
that file.

Invoking a mode is a significantly stronger signal.


        Stefan

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

[Alan Mackenzie]

Hello, Eli.

On Thu, Nov 14, 2024 at 08:59:32 +0200, Eli Zaretskii wrote:
> > Date: Wed, 13 Nov 2024 22:34:19 +0000
> > Cc: 74339@debbugs.gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>,
> >   acm@muc.de
> > From: Alan Mackenzie <acm@muc.de>

[ .... ]

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

> Of course!  That's what happens by default if the user didn't load
> c-ts-mode, and (under my suggested idea of a change) will happen if
> the user loads cc-mode after loading c-ts-mode.  IOW, the last mode
> loaded will "win".

This is also not ideal, in that M-x c-ts-mode will mostly not change the
preferred mode, but will do if it causes an autoload.  I've been trying
to think up something better, but all that springs to mind would be two
commands `cc-mode-prefer' and `c-ts-mode-prefer'.

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

> No, it won't.  This could happen only if the user loads c-ts-mode
> in-between, which means the user prefers c-ts-mode.  Without that,
> normal-mode will always revert to c-mode in the default Emacs
> configuration.

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

> Reverting the buffer activates whatever major mode corresponds to the
> file name and other relevant settings at the moment of the reverting.
> If you modify those settings in-between, it is quite possible (and
> expected!) that normal-mode will activate a different mode.  This is
> how Emacs always behaved (and should keep behaving).  Anything else is
> against user expectations.

OK, let's agree to disagree on this one.  As a user, when I was comparing
the two modes, I got annoyed at Emacs continually changing my major
modes.  I may not be the only one.  Maybe (for Emacs 31?) there could be
a user option to control this.

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

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

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Dmitry Gutov]

On 14/11/2024 17:51, Stefan Monnier wrote:
>> I'm personally skeptical that loading a package (or invoking a mode)
>> indicates a strong user preference, but ok, let's call it that.
> Indeed, I think loading a package does not show a strong user
> preference.  As we've seen, it can happen "by accident" in various
> circumstances that are only loosely related to using the code in
> that file.
> 
> Invoking a mode is a significantly stronger signal.

Stronger yes, but is it strong? One might as well be testing the mode, 
without intention to set it up as the default. And how much does it help 
anyway? The result can only last until the end of the current session, 
after which the user would need to use one of the other approaches.

Anyway, this is not a new argument.

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Alan Mackenzie <acm@muc.de>,
>   74339@debbugs.gnu.org
> Date: Thu, 14 Nov 2024 10:51:34 -0500
> 
> > I'm personally skeptical that loading a package (or invoking a mode)
> > indicates a strong user preference, but ok, let's call it that.
> 
> Indeed, I think loading a package does not show a strong user
> preference.  As we've seen, it can happen "by accident" in various
> circumstances that are only loosely related to using the code in
> that file.
> 
> Invoking a mode is a significantly stronger signal.

But AFAIU the code in both c-ts-mode and cc-mode is written such that
just invoking the mode (after the mode's package was loaded once)
doesn't modify major-mode-remap-defaults.  So unless I'm missing
something, the current code doesn't support what you think should be
the way for users to express their preference.

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

[Eli Zaretskii]

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

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> Indeed, I think loading a package does not show a strong user
>> preference.  As we've seen, it can happen "by accident" in various
>> circumstances that are only loosely related to using the code in
>> that file.
>> Invoking a mode is a significantly stronger signal.

Dmitry wrote:
> Stronger yes, but is it strong? One might as well be testing the mode,
> without intention to set it up as the default.  And how much does it
> help anyway?  The result can only last until the end of the current
> session, after which the user would need to use one of the
> other approaches.

I can't disagree.

Eli wrote:
> But AFAIU the code in both c-ts-mode and cc-mode is written such that
> just invoking the mode (after the mode's package was loaded once)
> doesn't modify major-mode-remap-defaults.

Indeed.  I had proposed a patch which sets `major-mode-remap-*` when we
enable the mode rather than when we load it, but it was rejected because
supposedly it did not correspond to the "least bad" compromise that
resulted from a long discussion.

> So unless I'm missing something, the current code doesn't support what
> you think should be the way for users to express their preference.

AFAIC, "the way for users to express their preference" is by customizing
`major-mode-remap-alist` and is a different issue than the setting of
`major-mode-remap-default` we're discussing, which is about trying to
*guess* the user's preference.


        Stefan

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> Of course!  That's what happens by default if the user didn't load
>> c-ts-mode, and (under my suggested idea of a change) will happen if
>> the user loads cc-mode after loading c-ts-mode.  IOW, the last mode
>> loaded will "win".
>
> This is also not ideal, in that M-x c-ts-mode will mostly not change the
> preferred mode, but will do if it causes an autoload.  I've been trying
> to think up something better, but all that springs to mind would be two
> commands `cc-mode-prefer' and `c-ts-mode-prefer'.

There are two issues: setting `major-mode-remap-defaults` which is about
guessing what the user's preference should be, and setting
`major-mode-remap-alist` which reflects an explicit user act to state
their preference.

New commands `cc-mode-prefer' and `c-ts-mode-prefer' would customize
`major-mode-remap-alist` whereas the code we're discussing is the one
that sets `major-mode-remap-defaults`.

Maybe we shouldn't set `major-mode-remap-defaults` at all, and instead
when the user calls `c-(ts-)mode` but the `major-mode-remap-alist`
selects the other mode, we should just emit a message telling the
users to customize `major-mode-remap-alist` (or to call `c*-mode-prefer`)
if they want to use that mode by default.

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

Not quite: `auto-mode-alist` should always map `.c` files to `c-mode`.
The choice between `c-mode` and `c-ts-mode` should be made
via `major-mode-remap-*`.  That's what those vars are for.
So loading either mode should not change `auto-mode-alist`.

IIUC the proposal to use the "last loaded" mode would be obtained, by
making the two files set `major-mode-remap-defaults` accordingly.
`c-ts-mode.el` already does that, so all we need is to change
`cc-mode.el` so it puts itself first but doesn't prevent `c-ts-mode.el`
from putting itself first in the future (contrary to what it currently
does).

The patch I sent earlier should do just that (by removing the entries
added by `c-ts-mode.el` rather than by adding entries, so as to avoid
growing `major-mode-remap-defaults` unnecessarily).


        Stefan

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

[Alan Mackenzie]

Hello, Eli.

On Thu, Nov 14, 2024 at 18:59:53 +0200, Eli Zaretskii wrote:
> > 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>

[ .... ]

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

OK, I can manage that.

I'll just outline a quick outline of what I see is to be done, so as to
fix any misunderstandings before starting to hack the code:

(i) CC Mode and c-ts-mode will both keep their autoload directives.
(ii) On loading either library, all their auto-mode-alist entries will be
  refreshed.  By "refresh" is meant they will be removed from
  auto-mode-alist (if present) and put back again at the top of that
  alist.
(iii) Evaluating a mode command does not change auto-mode-alist (except
  when it causes an autoload).
(iv) The manipulations of major-mode-remap-defaults by both libraries
  will be removed, since they are redundant.

Any comments?

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> (ii) On loading either library, all their auto-mode-alist entries will be
>   refreshed.  By "refresh" is meant they will be removed from
>   auto-mode-alist (if present) and put back again at the top of that
>   alist.

Please don't touch `auto-mode-alist`.
Only touch `major-mode-remap-defaults`.


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: dmitry@gutov.dev,  acm@muc.de,  74339@debbugs.gnu.org
> Date: Thu, 14 Nov 2024 12:16:38 -0500
> 
> AFAIC, "the way for users to express their preference" is by customizing
> `major-mode-remap-alist`

This is not a user-friendly method, IMNSHO.  Customizing
major-mode-remap-alist requires too much knowledge of Lisp.  How hard
is it to imagine someone who puts wrongly-formatted elements into the
alist, like sub-lists instead of cons cells?

If the user just wants to tell Emacs: I want to use foo-ts-mode
instead of foo-mode for language foo, there must be an easier way,
like flipping some simple switch.

So customizing major-mode-remap-alist is _a_ way to express this kind
of preferences, but IMO we should be able to do better.

In another discussion, I proposed to have simpler user option(s) that
would allow users to express this preference, such that, say,
auto-mode-alist would activate this or that mode given such a
variable.  I hope something like that will be possible in some future
release.

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  74339@debbugs.gnu.org
> Date: Thu, 14 Nov 2024 12:29:49 -0500
> 
> Not quite: `auto-mode-alist` should always map `.c` files to `c-mode`.

Why "always"?

> The choice between `c-mode` and `c-ts-mode` should be made
> via `major-mode-remap-*`.

That's one implementation, but it isn't the only one, and I'm not sure
it is the best one.

> That's what those vars are for.

major-mode-remap-alist is for remapping major modes in general, for
whatever reasons.  The non-TS vs TS modes is just one case where it
can be used, but it is not the only one, and maybe not even the most
important one.

> So loading either mode should not change `auto-mode-alist`.

It doesn't have to be due to loading the mode, it could be due to the
user flipping some option.  auto-mode-alist could stay the same, but
the result of looking up the proper mode for a .c file will be
different, depending on such a user option.

> IIUC the proposal to use the "last loaded" mode would be obtained, by
> making the two files set `major-mode-remap-defaults` accordingly.
> `c-ts-mode.el` already does that, so all we need is to change
> `cc-mode.el` so it puts itself first but doesn't prevent `c-ts-mode.el`
> from putting itself first in the future (contrary to what it currently
> does).

I think both files should first remove the existing elements that
remap c-mode and c++-mode.  Otherwise add-to-list will do nothing.

> The patch I sent earlier should do just that (by removing the entries
> added by `c-ts-mode.el` rather than by adding entries, so as to avoid
> growing `major-mode-remap-defaults` unnecessarily).

This is not enough, I think.  What will happen if, by some
happenstance, major-mode-remap-defaults has both elements added by
cc-mode and those added by c-ts-mode?

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

[Eli Zaretskii]

> Date: Thu, 14 Nov 2024 17:45:28 +0000
> Cc: 74339@debbugs.gnu.org, monnier@iro.umontreal.ca, acm@muc.de
> From: Alan Mackenzie <acm@muc.de>
> 
> Hello, Eli.
> 
> On Thu, Nov 14, 2024 at 18:59:53 +0200, Eli Zaretskii wrote:
> > > 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>
> 
> [ .... ]
> 
> > > 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?
> 
> OK, I can manage that.
> 
> I'll just outline a quick outline of what I see is to be done, so as to
> fix any misunderstandings before starting to hack the code:
> 
> (i) CC Mode and c-ts-mode will both keep their autoload directives.
> (ii) On loading either library, all their auto-mode-alist entries will be
>   refreshed.  By "refresh" is meant they will be removed from
>   auto-mode-alist (if present) and put back again at the top of that
>   alist.
> (iii) Evaluating a mode command does not change auto-mode-alist (except
>   when it causes an autoload).
> (iv) The manipulations of major-mode-remap-defaults by both libraries
>   will be removed, since they are redundant.
> 
> Any comments?

I prefer to make a simpler and more localized change, which only
manipulates major-mode-remap-defaults.  I would not like to risk
changes like modifying auto-mode-alist, which might have other
unintended consequences, at least on the release branch.  Let's stay
with major-mode-remap-defaults, since we already understand well
enough what the code does, and need just to tweak it in minor ways.

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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


        Stefan

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> AFAIC, "the way for users to express their preference" is by customizing
>> `major-mode-remap-alist`
> This is not a user-friendly method, IMNSHO.  Customizing
> major-mode-remap-alist requires too much knowledge of Lisp.  How hard
> is it to imagine someone who puts wrongly-formatted elements into the
> alist, like sub-lists instead of cons cells?

We can provide nicer UIs of course.

> In another discussion, I proposed to have simpler user option(s) that
> would allow users to express this preference, such that, say,
> auto-mode-alist would activate this or that mode given such a
> variable.

As long as it applies to the other ways to specify modes, rather than
being specifically for `auto-mode-alist`...


        Stefan

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

[Alan Mackenzie]

Hello, Eli.

On Thu, Nov 14, 2024 at 21:23:41 +0200, Eli Zaretskii wrote:
> > Date: Thu, 14 Nov 2024 17:45:28 +0000
> > Cc: 74339@debbugs.gnu.org, monnier@iro.umontreal.ca, acm@muc.de
> > From: Alan Mackenzie <acm@muc.de>

> > On Thu, Nov 14, 2024 at 18:59:53 +0200, Eli Zaretskii wrote:
> > > > 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>

> > [ .... ]

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

> > OK, I can manage that.

> > I'll just outline a quick outline of what I see is to be done, so as to
> > fix any misunderstandings before starting to hack the code:

> > (i) CC Mode and c-ts-mode will both keep their autoload directives.
> > (ii) On loading either library, all their auto-mode-alist entries will be
> >   refreshed.  By "refresh" is meant they will be removed from
> >   auto-mode-alist (if present) and put back again at the top of that
> >   alist.
> > (iii) Evaluating a mode command does not change auto-mode-alist (except
> >   when it causes an autoload).
> > (iv) The manipulations of major-mode-remap-defaults by both libraries
> >   will be removed, since they are redundant.

> > Any comments?

> I prefer to make a simpler and more localized change, which only
> manipulates major-mode-remap-defaults.  I would not like to risk
> changes like modifying auto-mode-alist, which might have other
> unintended consequences, at least on the release branch.

I thought we'd agreed to fix things by modifying auto-mode-alist.

What we definitely agreed was that the old modes and the tree-sitter
modes should be handled symmetrically, and that C Mode and friends
wouldn't be disadvantaged.

> Let's stay with major-mode-remap-defaults, since we already understand
> well enough what the code does, and need just to tweak it in minor
> ways.

OK, then the following suggests itself.  We have symbols like
`current-c-mode' which would be remapped in major-mode-defaults-alist,
and would be the cdrs of the entries in auto-mode-alist.  We would remap
`current-c-mode' each time cc-mode.el or c-ts-mode.el was loaded.  This
would avoid the need to modify auto-mode-alist at run time, and also
avoid all the disadvantages of remapping `c-mode' itself.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Eli Zaretskii]

> Date: Thu, 14 Nov 2024 19:53:33 +0000
> Cc: 74339@debbugs.gnu.org, monnier@iro.umontreal.ca, acm@muc.de
> From: Alan Mackenzie <acm@muc.de>
> 
> > I prefer to make a simpler and more localized change, which only
> > manipulates major-mode-remap-defaults.  I would not like to risk
> > changes like modifying auto-mode-alist, which might have other
> > unintended consequences, at least on the release branch.
> 
> I thought we'd agreed to fix things by modifying auto-mode-alist.

I wasn't aware of that.  I apologize if I missed some words to that
effect.  I thought we were always talking about fixing the values
pushed into major-mode-remap-defaults.

> What we definitely agreed was that the old modes and the tree-sitter
> modes should be handled symmetrically, and that C Mode and friends
> wouldn't be disadvantaged.

Yes.

> > Let's stay with major-mode-remap-defaults, since we already understand
> > well enough what the code does, and need just to tweak it in minor
> > ways.
> 
> OK, then the following suggests itself.  We have symbols like
> `current-c-mode' which would be remapped in major-mode-defaults-alist,
> and would be the cdrs of the entries in auto-mode-alist.  We would remap
> `current-c-mode' each time cc-mode.el or c-ts-mode.el was loaded.  This
> would avoid the need to modify auto-mode-alist at run time, and also
> avoid all the disadvantages of remapping `c-mode' itself.

There's no current-c-mode in Emacs now.  So doing it that way would
mean significant changes to Emacs, and I'd like to avoid that on the
release branch.

What I meant is to modify cc-mode so that it removes the entries
pushed to major-mode-remap-defaults by c-ts-mode and then pushes its
own entries which map c-mode etc. to themselves.  And c-ts-mode will
be changed to do the opposite.  This is a small, localized change,
which will leave everything else intact, and will allow users to
express their preferences by just loading the mode they want to use.

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: acm@muc.de,  74339@debbugs.gnu.org
> Date: Thu, 14 Nov 2024 14:38:59 -0500
> 
> >> 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 ...

You assume that people will always want to remap all of those to the
same mode?  And that no one will ever want to have, say, files with
the -*- c -*- cookie to use c-mode and nothing else?  Some might, even
if the majority won't.

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

[Alan Mackenzie]

Hello, Eli.

On Thu, Nov 14, 2024 at 22:21:02 +0200, Eli Zaretskii wrote:
> > Date: Thu, 14 Nov 2024 19:53:33 +0000
> > Cc: 74339@debbugs.gnu.org, monnier@iro.umontreal.ca, acm@muc.de
> > From: Alan Mackenzie <acm@muc.de>

> > > I prefer to make a simpler and more localized change, which only
> > > manipulates major-mode-remap-defaults.  I would not like to risk
> > > changes like modifying auto-mode-alist, which might have other
> > > unintended consequences, at least on the release branch.

> > I thought we'd agreed to fix things by modifying auto-mode-alist.

> I wasn't aware of that.  I apologize if I missed some words to that
> effect.  I thought we were always talking about fixing the values
> pushed into major-mode-remap-defaults.

> > What we definitely agreed was that the old modes and the tree-sitter
> > modes should be handled symmetrically, and that C Mode and friends
> > wouldn't be disadvantaged.

> Yes.

> > > Let's stay with major-mode-remap-defaults, since we already understand
> > > well enough what the code does, and need just to tweak it in minor
> > > ways.

> > OK, then the following suggests itself.  We have symbols like
> > `current-c-mode' which would be remapped in major-mode-defaults-alist,
> > and would be the cdrs of the entries in auto-mode-alist.  We would remap
> > `current-c-mode' each time cc-mode.el or c-ts-mode.el was loaded.  This
> > would avoid the need to modify auto-mode-alist at run time, and also
> > avoid all the disadvantages of remapping `c-mode' itself.

> There's no current-c-mode in Emacs now.  So doing it that way would
> mean significant changes to Emacs, and I'd like to avoid that on the
> release branch.

> What I meant is to modify cc-mode so that it removes the entries
> pushed to major-mode-remap-defaults by c-ts-mode and then pushes its
> own entries which map c-mode etc. to themselves.  And c-ts-mode will
> be changed to do the opposite.  This is a small, localized change,
> which will leave everything else intact, and will allow users to
> express their preferences by just loading the mode they want to use.

How is that symmetrical between c-mode and c-ts-mode?  The very nature of
the entries you're intending to make in major-mode-remap-defaults is
asymmetric, in that they would remap `c-mode', but wouldn't remap
`c-ts-mode'.  Or have I missed something?

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> >> 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 ...
>
> You assume that people will always want to remap all of those to the
> same mode?

Not always but in the vast majority of cases, yes.

> And that no one will ever want to have, say, files with the -*- c -*-
> cookie to use c-mode and nothing else?  Some might, even if the
> majority won't.

Those few who want that can still get it: just config
`major-mode-remap-alist` to remap `c-mode` to `c-mode` (or to nil), and
then things work as if `major-mode-remap-*` didn't exist: `-*- c -*-`
will mean to use CC-mode's `c-mode` and `-*- c-ts -*-` will use
`c-ts-mode`.


        Stefan

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> What I meant is to modify cc-mode so that it removes the entries
>> pushed to major-mode-remap-defaults by c-ts-mode and then pushes its
>> own entries which map c-mode etc. to themselves.

For `major-mode-remap-defaults`, mapping `c-mode` to `c-mode` behaves
the same as when there is simply no entry mapping `c-mode` to anything,
which is why the code I suggested (which just removes any previous
remapping of `c-mode`) should give the same result as what you describe.

> How is that symmetrical between c-mode and c-ts-mode?  The very nature of
> the entries you're intending to make in major-mode-remap-defaults is
> asymmetric, in that they would remap `c-mode', but wouldn't remap
> `c-ts-mode'.  Or have I missed something?

They'd be symmetric in the sense that the mode used by default is
the one that was last loaded (with a "default default" of `c-mode`).

The apparent asymmetry is compensated by the fact that the entries in
`auto-mode-alist` always say `c-mode` and never `c-ts-mode`, so there's
never a need to remap `c-ts-mode` to `c-mode`.


        Stefan

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

For reference, here's the patch I'm suggesting.


        Stefan


diff --git a/lisp/progmodes/cc-mode.el b/lisp/progmodes/cc-mode.el
index 8ce4da56ef7..2e985ef9a83 100644
--- a/lisp/progmodes/cc-mode.el
+++ b/lisp/progmodes/cc-mode.el
@@ -3331,16 +3331,11 @@ c-submit-bug-report
 ;; Mode has been loaded, the symbols `c-mode' etc., will call CC Mode's
 ;; modes rather than c-ts-mode etc..
 (when (boundp 'major-mode-remap-defaults)
-  (add-to-list 'major-mode-remap-defaults '(c++-mode . c++-ts-mode))
-  (add-to-list 'major-mode-remap-defaults '(c-mode . c-ts-mode))
-  (add-to-list 'major-mode-remap-defaults '(c-or-c++-mode . c-or-c++-ts-mode))
   (let (entry)
     (dolist (mode '(c-mode c++-mode c-or-c++-mode))
-      (if (and (setq entry (assq mode major-mode-remap-defaults))
-	       (null (cdr entry)))
-	  (setq major-mode-remap-defaults
-		(delq entry major-mode-remap-defaults)))
-      (push (cons mode nil) major-mode-remap-defaults))))
+      (while (setq entry (assq mode major-mode-remap-defaults))
+	(setq major-mode-remap-defaults
+	      (delq entry major-mode-remap-defaults))))))
 
 \f
 (cc-provide 'cc-mode)

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

BTW, we should also install a patch like the one below.
Any objection?


        Stefan


diff --git a/lisp/progmodes/c-ts-mode.el b/lisp/progmodes/c-ts-mode.el
index 3823c553fda..8d6e05f8008 100644
--- a/lisp/progmodes/c-ts-mode.el
+++ b/lisp/progmodes/c-ts-mode.el
@@ -33,31 +33,15 @@
 ;; C/C++ header files.
 ;;
 ;; To use these modes by default, assuming you have the respective
-;; tree-sitter grammars available, do one of the following:
-;;
-;; - If you have both C and C++ grammars installed, add
-;;
-;;    (require 'c-ts-mode)
-;;
-;;   to your init file.
-;;
-;; - Add one or mode of the following to your init file:
+;; tree-sitter grammars available,
+;; add one or more of the following to your init file:
 ;;
 ;;    (add-to-list 'major-mode-remap-alist '(c-mode . c-ts-mode))
 ;;    (add-to-list 'major-mode-remap-alist '(c++-mode . c++-ts-mode))
 ;;    (add-to-list 'major-mode-remap-alist '(c-or-c++-mode . c-or-c++-ts-mode))
 ;;
-;;   If you have only C grammar available, use only the first one; if
-;;   you have only the C++ grammar, use only the second one.
-;;
-;; - Customize 'auto-mode-alist' to turn one or more of the modes
-;;   automatically.  For example:
-;;
-;;     (add-to-list 'auto-mode-alist
-;;                  '("\\(\\.ii\\|\\.\\(CC?\\|HH?\\)\\|\\.[ch]\\(pp\\|xx\\|\\+\\+\\)\\|\\.\\(cc\\|hh\\)\\)\\'"
-;;                    . c++-ts-mode))
-;;
-;;   will turn on the c++-ts-mode for C++ source files.
+;; If you have only C grammar available, use only the first one; if
+;; you have only the C++ grammar, use only the second one.
 ;;
 ;; You can also turn on these modes manually in a buffer.  Doing so
 ;; will set up Emacs to use the C/C++ modes defined here for other

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

[Eli Zaretskii]

> Date: Thu, 14 Nov 2024 20:38:40 +0000
> Cc: 74339@debbugs.gnu.org, monnier@iro.umontreal.ca, acm@muc.de
> From: Alan Mackenzie <acm@muc.de>
> 
> > What I meant is to modify cc-mode so that it removes the entries
> > pushed to major-mode-remap-defaults by c-ts-mode and then pushes its
> > own entries which map c-mode etc. to themselves.  And c-ts-mode will
> > be changed to do the opposite.  This is a small, localized change,
> > which will leave everything else intact, and will allow users to
> > express their preferences by just loading the mode they want to use.
> 
> How is that symmetrical between c-mode and c-ts-mode?  The very nature of
> the entries you're intending to make in major-mode-remap-defaults is
> asymmetric, in that they would remap `c-mode', but wouldn't remap
> `c-ts-mode'.  Or have I missed something?

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.  This is the issue at hand: to allow users to express their
preferences about c-mode in a way that is reversible.  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.

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.  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.  With that concept, remapping
c-ts-mode to c-mode makes very little sense.  But this all is not yet
finalized, certainly not in Emacs 30, and thus is not relevant to the
release branch, which is my main concern in this bug report.)

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: acm@muc.de,  74339@debbugs.gnu.org
> Date: Thu, 14 Nov 2024 15:58:49 -0500
> 
> >> >> 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 ...
> >
> > You assume that people will always want to remap all of those to the
> > same mode?
> 
> Not always but in the vast majority of cases, yes.
> 
> > And that no one will ever want to have, say, files with the -*- c -*-
> > cookie to use c-mode and nothing else?  Some might, even if the
> > majority won't.
> 
> Those few who want that can still get it: just config
> `major-mode-remap-alist` to remap `c-mode` to `c-mode` (or to nil), and
> then things work as if `major-mode-remap-*` didn't exist: `-*- c -*-`
> will mean to use CC-mode's `c-mode` and `-*- c-ts -*-` will use
> `c-ts-mode`.

This will cause Emacs to visit C files without the cookie in c-mode.
What I meant was an (admittedly somewhat strange) preference to visit
C files without a cookie in c-ts-mode, but files that have a cookie in
the mode called out by the cookie.  AFAIU, major-mode-remap-*
variables cannot handle this distinction, at least not currently.

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  74339@debbugs.gnu.org
> Date: Thu, 14 Nov 2024 16:06:01 -0500
> 
> >> What I meant is to modify cc-mode so that it removes the entries
> >> pushed to major-mode-remap-defaults by c-ts-mode and then pushes its
> >> own entries which map c-mode etc. to themselves.
> 
> For `major-mode-remap-defaults`, mapping `c-mode` to `c-mode` behaves
> the same as when there is simply no entry mapping `c-mode` to anything,
> which is why the code I suggested (which just removes any previous
> remapping of `c-mode`) should give the same result as what you describe.

That's true, but only if the other elements whose car is c-mode were
first removed with 110% reliability.  If we want to be absolutely sure
that c-mode spec invokes c-mode and nothing else, adding '(c-mode) is
more reliable.

> The apparent asymmetry is compensated by the fact that the entries in
> `auto-mode-alist` always say `c-mode` and never `c-ts-mode`, so there's
> never a need to remap `c-ts-mode` to `c-mode`.

Right.

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  74339@debbugs.gnu.org
> Date: Thu, 14 Nov 2024 16:26:35 -0500
> 
> For reference, here's the patch I'm suggesting.
> 
> 
>         Stefan
> 
> 
> diff --git a/lisp/progmodes/cc-mode.el b/lisp/progmodes/cc-mode.el
> index 8ce4da56ef7..2e985ef9a83 100644
> --- a/lisp/progmodes/cc-mode.el
> +++ b/lisp/progmodes/cc-mode.el
> @@ -3331,16 +3331,11 @@ c-submit-bug-report
>  ;; Mode has been loaded, the symbols `c-mode' etc., will call CC Mode's
>  ;; modes rather than c-ts-mode etc..
>  (when (boundp 'major-mode-remap-defaults)
> -  (add-to-list 'major-mode-remap-defaults '(c++-mode . c++-ts-mode))
> -  (add-to-list 'major-mode-remap-defaults '(c-mode . c-ts-mode))
> -  (add-to-list 'major-mode-remap-defaults '(c-or-c++-mode . c-or-c++-ts-mode))
>    (let (entry)
>      (dolist (mode '(c-mode c++-mode c-or-c++-mode))
> -      (if (and (setq entry (assq mode major-mode-remap-defaults))
> -	       (null (cdr entry)))
> -	  (setq major-mode-remap-defaults
> -		(delq entry major-mode-remap-defaults)))
> -      (push (cons mode nil) major-mode-remap-defaults))))
> +      (while (setq entry (assq mode major-mode-remap-defaults))
> +	(setq major-mode-remap-defaults
> +	      (delq entry major-mode-remap-defaults))))))

Thanks, but wouldn't it be better to use assq-delete-all?  Your
proposed code deletes only the first entry found in the alist.  But
what if the alist has both '(c-mode . c-ts-mode) and '(c-mode) ?  Then
the second one will not be removed from the alist, AFAIU.

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: acm@muc.de,  74339@debbugs.gnu.org
> Date: Thu, 14 Nov 2024 17:06:13 -0500
> 
> BTW, we should also install a patch like the one below.
> Any objection?

I don't think we should install this, no, definitely not on the
emacs-30 branch.  It was never my intention that Emacs 30 will affect
the advice in those comments.

We could (and probably should) consider some kind of changes for Emacs
31.  But since we don't yet have a clear idea of how we want this to
be resolved from the users' POV, it is too early to consider changes
to this text even on master.

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

[Alan Mackenzie]

Hello, Eli.

On Fri, Nov 15, 2024 at 09:33:17 +0200, Eli Zaretskii wrote:
> > Date: Thu, 14 Nov 2024 20:38:40 +0000
> > Cc: 74339@debbugs.gnu.org, monnier@iro.umontreal.ca, acm@muc.de
> > From: Alan Mackenzie <acm@muc.de>

> > > What I meant is to modify cc-mode so that it removes the entries
> > > pushed to major-mode-remap-defaults by c-ts-mode and then pushes its
> > > own entries which map c-mode etc. to themselves.  And c-ts-mode will
> > > be changed to do the opposite.  This is a small, localized change,
> > > which will leave everything else intact, and will allow users to
> > > express their preferences by just loading the mode they want to use.

> > How is that symmetrical between c-mode and c-ts-mode?  The very nature of
> > the entries you're intending to make in major-mode-remap-defaults is
> > asymmetric, in that they would remap `c-mode', but wouldn't remap
> > `c-ts-mode'.  Or have I missed something?

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

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

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.

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

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

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.

> 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.  I think it's the best
solution available at the moment, as well as being the one we agreed to
yesterday.

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

As I've already said, I think the -*- c -*- cookie ought to mean the
current C mode, not C Mode, and that I've an implementation which does
that.  But that is surely a different issue from what we're discussing
in this thread.

> With that concept, remapping c-ts-mode to c-mode makes very little
> sense.  But this all is not yet finalized, certainly not in Emacs 30,
> and thus is not relevant to the release branch, which is my main
> concern in this bug report.)

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Eli Zaretskii]

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

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> This will cause Emacs to visit C files without the cookie in c-mode.
> What I meant was an (admittedly somewhat strange) preference to visit
> C files without a cookie in c-ts-mode, but files that have a cookie in
> the mode called out by the cookie.  AFAIU, major-mode-remap-*
> variables cannot handle this distinction, at least not currently.

No, indeed, they don't help with that.  They don't prevent it either, tho:
Users can still get that kind of behavior with the "old methods" such as
by changing `auto-mode-alist` to map `.c` files to `c-ts-mode`.


        Stefan

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> diff --git a/lisp/progmodes/cc-mode.el b/lisp/progmodes/cc-mode.el
>> index 8ce4da56ef7..2e985ef9a83 100644
>> --- a/lisp/progmodes/cc-mode.el
>> +++ b/lisp/progmodes/cc-mode.el
>> @@ -3331,16 +3331,11 @@ c-submit-bug-report
>>  ;; Mode has been loaded, the symbols `c-mode' etc., will call CC Mode's
>>  ;; modes rather than c-ts-mode etc..
>>  (when (boundp 'major-mode-remap-defaults)
>> -  (add-to-list 'major-mode-remap-defaults '(c++-mode . c++-ts-mode))
>> -  (add-to-list 'major-mode-remap-defaults '(c-mode . c-ts-mode))
>> -  (add-to-list 'major-mode-remap-defaults '(c-or-c++-mode . c-or-c++-ts-mode))
>>    (let (entry)
>>      (dolist (mode '(c-mode c++-mode c-or-c++-mode))
>> -      (if (and (setq entry (assq mode major-mode-remap-defaults))
>> -	       (null (cdr entry)))
>> -	  (setq major-mode-remap-defaults
>> -		(delq entry major-mode-remap-defaults)))
>> -      (push (cons mode nil) major-mode-remap-defaults))))
>> +      (while (setq entry (assq mode major-mode-remap-defaults))
>> +	(setq major-mode-remap-defaults
>> +	      (delq entry major-mode-remap-defaults))))))
>
> Thanks, but wouldn't it be better to use assq-delete-all?

Oh, indeed, I forgot about that one; that makes it even simpler, thanks.

> Your proposed code deletes only the first entry found in the alist.

I don't think so: the code uses a `while` to remove them all.
[ The code I had sent a few days ago did suffer from the problem you
  describe, tho, so I assume you just presumed it was the same code.  🙂]


        Stefan

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

[Alan Mackenzie]

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