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