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

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

[Dmitry Gutov]

Hi Alan,

On 15/11/2024 15:04, Alan Mackenzie wrote:
>> 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?

Allow me to butt in this subthread a little. Your other points aside - 
several of them definitely valid - there already is an inherent 
asymmetry between c/c++ ts modes and cc-mode in that we give deference 
to the latter in our default file->mode mappings, which I wouldn't 
expect to change in any short or medium term.

So if we give a little back to ts modes on another level (and assuming 
user opt-in), that seems fair enough.

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]

> One can write, in the Local Variables: section
>
>     mode: c-ts

FWIW, unless this file is personal, this is very bad practice, and not
only because `c-ts-mode` may not be available (in older Emacsen or if
the user didn't build Emacs with tree-sitter support or doesn't have the
appropriate grammar installed): the choice between `c-mode` and
`c-ts-mode` is a personal preference, so it's not the file's business to
tell the user which mode to use, just like it's not the file's business
to tell the user which editor to use.

There might be special situations where such a setting might be
warranted, but they're sufficiently hypothetical or rare that they
should not drive our decisions, as long as the users can still get the
behavior they want in such cases (which they can, regardless of what we
do with `major-mode-remap-defaults`).

> ..  This will cause the buffer to start in c-ts-mode regardless of any
> other current settings.

Actually, no: `major-mode-remap-*` can also remap `c-ts-mode` to some
other mode, such as `c-mode`.

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

If you really insist, we can add

    (add-to-list 'major-mode-remap-defaults '(c-ts-mode . c-mode))
    (add-to-list 'major-mode-remap-defaults '(c++-ts-mode . c++-mode))

to your `cc-mode.el` together with corresponding removals in
`c-ts-mode.el`, even though in my book file-local settings of
`mode: c-ts-mode` in non-personal files are just bugs.

> ... there will be no way for a user to specify c-mode unambiguously ...

Where/when?  AFAICT the only case where this might be true are the cases
where it does not do any damage.

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

It is supposed to opt-in, indeed.


        Stefan

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

[Alan Mackenzie]

Hello, Stefan.

On Fri, Nov 15, 2024 at 14:01:26 -0500, Stefan Monnier wrote:
> > One can write, in the Local Variables: section

> >     mode: c-ts

> FWIW, unless this file is personal, this is very bad practice, and not
> only because `c-ts-mode` may not be available (in older Emacsen or if
> the user didn't build Emacs with tree-sitter support or doesn't have the
> appropriate grammar installed): the choice between `c-mode` and
> `c-ts-mode` is a personal preference, so it's not the file's business to
> tell the user which mode to use, just like it's not the file's business
> to tell the user which editor to use.

> There might be special situations where such a setting might be
> warranted, but they're sufficiently hypothetical or rare that they
> should not drive our decisions, as long as the users can still get the
> behavior they want in such cases (which they can, regardless of what we
> do with `major-mode-remap-defaults`).

Here is a section of a test file sent to bug-cc-mode some while ago:

/*
** Local Variables:
** mode:c
** indent-tabs-mode:nil
** c-basic-offset:4
** End:
*/

Here it is evident that by "mode:c" the OP means C Mode, not whatever
random mode happens to have taken the symbol `c-mode'.

> > ..  This will cause the buffer to start in c-ts-mode regardless of any
> > other current settings.

> Actually, no: `major-mode-remap-*` can also remap `c-ts-mode` to some
> other mode, such as `c-mode`.

Maybe I should have said "regardless of any non-crazy settings".

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

> If you really insist, we can add

>     (add-to-list 'major-mode-remap-defaults '(c-ts-mode . c-mode))
>     (add-to-list 'major-mode-remap-defaults '(c++-ts-mode . c++-mode))

> to your `cc-mode.el` together with corresponding removals in
> `c-ts-mode.el`, even though in my book file-local settings of
> `mode: c-ts-mode` in non-personal files are just bugs.

The problem is that entries in major-mode-remap-defaults (and the other
one) do not accurately represent user preferences.

As a value for mode: in C files, we need three distinct settings: for C
Mode, for c-ts-mode, and for any mode which handles C.  Currently we've
only got two: c-mode and c-ts-mode.  This can't work properly.

> > ... there will be no way for a user to specify c-mode unambiguously ...

> Where/when?  AFAICT the only case where this might be true are the cases
> where it does not do any damage.

In an auto-mode-alist entry, for example.  As already discussed, in a
Local Variables: section, for another example.

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

> It is supposed to opt-in, indeed.

So, for a user trying out Emacs 30, with a desktop file containing at
least one file with major mode c-ts-mode; visiting a file with the above
Local Variables section will indeed start the buffer with C Mode?

I haven't looked just yet, but can I assume there's a recipe in the
Emacs 30 NEWS file telling users how to switch between old behaviour
(-*- c -*- always means C mode) and new behaviour (-*- c -*- can mean
c-ts-mode depending on other settings)?  Is the default to keep the old
behaviour, as is customary with new features in Emacs?

>         Stefan

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

> Here is a section of a test file sent to bug-cc-mode some while ago:
>
> /*
> ** Local Variables:
> ** mode:c
> ** indent-tabs-mode:nil
> ** c-basic-offset:4
> ** End:
> */
>
> Here it is evident that by "mode:c" the OP means C Mode, not whatever
> random mode happens to have taken the symbol `c-mode'.

It is evident that the OP means CC-mode's C Mode because the bug report
is sent to `bug-cc-mode`, indeed.

But that doesn't mean these file-local settings intend to impose the use
of CC-mode to those users who prefer `c-ts-mode`.

>> Actually, no: `major-mode-remap-*` can also remap `c-ts-mode` to some
>> other mode, such as `c-mode`.
> Maybe I should have said "regardless of any non-crazy settings".

If something is "crazy" here it would be using a `mode: c-ts` cookie.
Adding such entries to `major-mode-remap-*` would just be the sane way
to work around that "crazy" part.  🙂

>> If you really insist, we can add
>>     (add-to-list 'major-mode-remap-defaults '(c-ts-mode . c-mode))
>>     (add-to-list 'major-mode-remap-defaults '(c++-ts-mode . c++-mode))
>> to your `cc-mode.el` together with corresponding removals in
>> `c-ts-mode.el`, even though in my book file-local settings of
>> `mode: c-ts-mode` in non-personal files are just bugs.
> The problem is that entries in major-mode-remap-defaults (and the other
> one) do not accurately represent user preferences.

Entries in `major-mode-remap-defaults` indeed do not reflect
a user preference, just a "circumstantial" preference.

[ Ideally, they shouldn't be set just by loading a file (whether
  `cc-mode.el` or `c-ts-mode.el`).  But after a long protracted
  discussion the Emacs maintainers decided that it was the least bad
  choice in Emacs-29.  This may be revisited in the future, e.g. for
  Emacs-31, but AFAICT it's too late to make such a change in
  Emacs-30.  ]

But entries in `major-mode-remap-alist` very much reflect a user preference.

> As a value for mode: in C files, we need three distinct settings: for
> C Mode, for c-ts-mode, and for any mode which handles C.

If someone sends me a file which says `mode: c-ts`, I will complain
and so should anyone else.  Whether you edit it with `c-mode` or with
`c-ts-mode` is not the file's business.

>> It is supposed to opt-in, indeed.
> So, for a user trying out Emacs 30, with a desktop file containing at
> least one file with major mode c-ts-mode; visiting a file with the above
> Local Variables section will indeed start the buffer with C Mode?

If you see a file that stipulates `c-ts-mode`, complain to the
file's author, not to us.

> I haven't looked just yet, but can I assume there's a recipe in the
> Emacs 30 NEWS file telling users how to switch between old behaviour
> (-*- c -*- always means C mode) and new behaviour (-*- c -*- can mean
> c-ts-mode depending on other settings)?

If anything, Emacs-30 makes it easier than Emacs-29:

    (add-to-list 'major-mode-remap-alist '(c-mode))

In Emacs-29, you had to go and undo the mess in `auto-mode-alist`.


        Stefan

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

[Stefan Kangas]

Alan Mackenzie <acm@muc.de> writes:

> On Fri, Nov 15, 2024 at 14:01:26 -0500, Stefan Monnier wrote:
>> > One can write, in the Local Variables: section
>
>> >     mode: c-ts
>
>> FWIW, unless this file is personal, this is very bad practice, and not
>> only because `c-ts-mode` may not be available (in older Emacsen or if
>> the user didn't build Emacs with tree-sitter support or doesn't have the
>> appropriate grammar installed): the choice between `c-mode` and
>> `c-ts-mode` is a personal preference, so it's not the file's business to
>> tell the user which mode to use, just like it's not the file's business
>> to tell the user which editor to use.

+1

> Here is a section of a test file sent to bug-cc-mode some while ago:
>
> /*
> ** Local Variables:
> ** mode:c
> ** indent-tabs-mode:nil
> ** c-basic-offset:4
> ** End:
> */
>
> Here it is evident that by "mode:c" the OP means C Mode, not whatever
> random mode happens to have taken the symbol `c-mode'.

Yes, that is how Emacs behaves by default.

However, the point of the new feature, major-mode-remap, is exactly to
allow users to override that.  This new feature is optional, and AFAICT
the user choice is explicit and not "random".

Clearly, c-mode is still favored, as it is the default, and many of us
continue being happy users of it even while running a treesitter build.
So this new feature very clearly only affects users that have somehow
explicitly indicated that they want to use c-ts-mode instead.

>> > ..  This will cause the buffer to start in c-ts-mode regardless of any
>> > other current settings.
>
>> Actually, no: `major-mode-remap-*` can also remap `c-ts-mode` to some
>> other mode, such as `c-mode`.
>
> Maybe I should have said "regardless of any non-crazy settings".

What makes anything about that setting crazy?

I'd use that setting, if I ever ran into any files with a "-*- c-ts -*-"
cookie.  Similarly, I expect that c-ts-mode users will want to use
c-ts-mode precisely when a file has a "-*- c -*-" cookie.

Again, being able to do that is exactly the point of major-mode-remap.
I struggle to understand why that flexibility is controversial.  It
puts more power into users' hands, that's all.

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

[Alan Mackenzie]

Hello, Stefan.

On Fri, Nov 15, 2024 at 12:58:02 -0800, Stefan Kangas wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > On Fri, Nov 15, 2024 at 14:01:26 -0500, Stefan Monnier wrote:

[ .... ]

> > Here is a section of a test file sent to bug-cc-mode some while ago:

> > /*
> > ** Local Variables:
> > ** mode:c
> > ** indent-tabs-mode:nil
> > ** c-basic-offset:4
> > ** End:
> > */

> > Here it is evident that by "mode:c" the OP means C Mode, not whatever
> > random mode happens to have taken the symbol `c-mode'.

> Yes, that is how Emacs behaves by default.

Only sort of, now.

> However, the point of the new feature, major-mode-remap, is exactly to
> allow users to override that.

No, it is only _approximately_ for that.  major-mode-remap-alist is for
that.  Modes using major-mode-remap-defaults override that setting
without the users have much of a say.

> This new feature is optional, and AFAICT the user choice is explicit
> and not "random".

No, that is the problem.  Have a look at major-mode-remap-defaults, and
how c-ts-mode uses it to cause the symbol `c-mode' to start c-ts-mode in
certain circumstances.  This is what I'm unhappy about.

> Clearly, c-mode is still favored, as it is the default, and many of us
> continue being happy users of it even while running a treesitter build.
> So this new feature very clearly only affects users that have somehow
> explicitly indicated that they want to use c-ts-mode instead.

That "somehow" is the loading of c-ts-mode.  I think that even C-h f
c-ts-mode counts as an "explicit indication" of a supposed preference for
c-ts-mode, given that it loads c-ts-mode (if it actually does).

I don't think the current mechanism is ready for the release of Emacs 30.
It hasn't been thought through thoroughly.

> >> > ..  This will cause the buffer to start in c-ts-mode regardless of any
> >> > other current settings.

> >> Actually, no: `major-mode-remap-*` can also remap `c-ts-mode` to some
> >> other mode, such as `c-mode`.

> > Maybe I should have said "regardless of any non-crazy settings".

> What makes anything about that setting crazy?

I think making a setting for c-ts-mode in order to get a buffer into
c-mode is crazy.  It is not the first thing one thinks about, faced with
the problem of a buffer going into the wrong mode.

> I'd use that setting, if I ever ran into any files with a "-*- c-ts -*-"
> cookie.  Similarly, I expect that c-ts-mode users will want to use
> c-ts-mode precisely when a file has a "-*- c -*-" cookie.

We don't have fine enough control.  /* mode: c */ followed by /*
c-basic-offset: 4 */ in the Local Variables: section is a sure sign that
C Mode is intended, not a random C handling mode.

What I think we're lacking is an explicit setting or command for the user
to state what her preferred mode for C actually is.
major-mode-remap-alist isn't that setting - it's too involved, too
awkward, and it talks about "remappinig modes" (its internal mechanism)
rather than the user's preferred Mode for C.  What we need is a defcustom
3-valued radio-button defaulting to "no explicit preference", and having
other values "c-mode" and "c-ts-mode".

> Again, being able to do that is exactly the point of major-mode-remap.
> I struggle to understand why that flexibility is controversial.  It
> puts more power into users' hands, that's all.

It involves c-ts-mode purloining CC Mode's symbols for its own use.  If a
user wishes to use major-mode-remap-alist for that, that's one thing -
having it done by default in major-mode-remap-defaults by Emacs is
something quite different, which I think is unacceptable.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Stefan Kangas]

Alan Mackenzie <acm@muc.de> writes:

> That "somehow" is the loading of c-ts-mode.  I think that even C-h f
> c-ts-mode counts as an "explicit indication" of a supposed preference for
> c-ts-mode, given that it loads c-ts-mode (if it actually does).

It seems like you're right about that, in emacs -Q.

FWIW, I consider that less than ideal, and would prefer that we did that
only when enabling the mode.  Loading files shouldn't change behaviour,
exactly for this reason.  So I'd be in favor of making such a change (on
master).  But that's me.

> I don't think the current mechanism is ready for the release of Emacs 30.
> It hasn't been thought through thoroughly.

I see no release blocker at this late stage, myself.

>> I'd use that setting, if I ever ran into any files with a "-*- c-ts -*-"
>> cookie.  Similarly, I expect that c-ts-mode users will want to use
>> c-ts-mode precisely when a file has a "-*- c -*-" cookie.
>
> We don't have fine enough control.  /* mode: c */ followed by /*
> c-basic-offset: 4 */ in the Local Variables: section is a sure sign that
> C Mode is intended, not a random C handling mode.
>
> What I think we're lacking is an explicit setting or command for the user
> to state what her preferred mode for C actually is.
> major-mode-remap-alist isn't that setting - it's too involved, too
> awkward, and it talks about "remappinig modes" (its internal mechanism)
> rather than the user's preferred Mode for C.

I think `major-mode-remap-alist` is the explicit setting that we have.
That said, I wouldn't personally close the door to a proposal that is
significantly better.  I'm just not sure what it would look like.

> What we need is a defcustom 3-valued radio-button defaulting to "no
> explicit preference", and having other values "c-mode" and
> "c-ts-mode".

The benefit of `major-mode-remap` is that it's sufficiently general not
just for c-mode/c-ts-mode, but for all other cases where we have two or
more modes, such as yaml-mode/yaml-ts-mode, etc.  And it will handle
whatever new modes we can dream up in the future.

It also fits in nicely with the equally general `auto-mode-alist`,
`interpreter-mode-alist`, etc., that we already have.

For these reasons, I think I prefer `major-mode-remap` to a specific
option just for c-mode/c-ts-mode.

>> Again, being able to do that is exactly the point of major-mode-remap.
>> I struggle to understand why that flexibility is controversial.  It
>> puts more power into users' hands, that's all.
>
> It involves c-ts-mode purloining CC Mode's symbols for its own use.  If a
> user wishes to use major-mode-remap-alist for that, that's one thing -
> having it done by default in major-mode-remap-defaults by Emacs is
> something quite different, which I think is unacceptable.

So you don't like the specific detail that it overloads the use of the
symbol `c-mode` as a proxy for saying C files?

FWIW, and AFAIR, I think we discussed this overloading of the mode name
on the list, and the other option was to introduce a new concept of
"languages" into Emacs Lisp, where we would have had alist entries like
`(c . c-mode)` instead.  The conclusion was that doing that would be
more complex and it was hard to justify this complication.  I can't
remember that any other ways to avoid this overloading were suggested.

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]

> No, that is the problem.  Have a look at major-mode-remap-defaults, and
> how c-ts-mode uses it to cause the symbol `c-mode' to start c-ts-mode in
> certain circumstances.  This is what I'm unhappy about.

In which way is this worse than what we have in Emacs-29 where loading
`c-ts-mode` does things like:

    (add-to-list 'auto-mode-alist
                 '("\\(\\.[chi]\\|\\.lex\\|\\.y\\(acc\\)?\\)\\'" . c-ts-mode))
    (add-to-list 'auto-mode-alist '("\\.x[pb]m\\'" . c-ts-mode))

?

> That "somehow" is the loading of c-ts-mode.  I think that even C-h f
> c-ts-mode counts as an "explicit indication" of a supposed preference for
> c-ts-mode, given that it loads c-ts-mode (if it actually does).

Yup, and the same happens in Emacs-29.

> I don't think the current mechanism is ready for the release of Emacs 30.

I don't see a regression here.

> We don't have fine enough control.  /* mode: c */ followed by /*
> c-basic-offset: 4 */ in the Local Variables: section is a sure sign that
> C Mode is intended, not a random C handling mode.

In your head, maybe.
I think for most users of other C modes (e.g. `c-ts-mode` or
`sm-c-mode`), the /* mode: c */ thingy just means that this file should
use their favorite major mode for C.

> What I think we're lacking is an explicit setting or command for the
> user to state what her preferred mode for C actually is.

You still haven't explained why the user's personal preference about the
major mode should be stated in the file.


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Stefan Kangas <stefankangas@gmail.com>,  Eli Zaretskii <eliz@gnu.org>,
>   74339@debbugs.gnu.org
> Date: Sat, 16 Nov 2024 01:17:41 -0500
> 
> > No, that is the problem.  Have a look at major-mode-remap-defaults, and
> > how c-ts-mode uses it to cause the symbol `c-mode' to start c-ts-mode in
> > certain circumstances.  This is what I'm unhappy about.
> 
> In which way is this worse than what we have in Emacs-29 where loading
> `c-ts-mode` does things like:
> 
>     (add-to-list 'auto-mode-alist
>                  '("\\(\\.[chi]\\|\\.lex\\|\\.y\\(acc\\)?\\)\\'" . c-ts-mode))
>     (add-to-list 'auto-mode-alist '("\\.x[pb]m\\'" . c-ts-mode))
> 
> ?
> 
> > That "somehow" is the loading of c-ts-mode.  I think that even C-h f
> > c-ts-mode counts as an "explicit indication" of a supposed preference for
> > c-ts-mode, given that it loads c-ts-mode (if it actually does).
> 
> Yup, and the same happens in Emacs-29.

Right.  Moreover, in Emacs 29 the modification of auto-mode-alist only
took care of visiting C files without a mode cookie.  In addition,
with Emacs 29, once the user loaded c-ts-mode, there was no way for
the user to go back to using C Mode; with the changes we propose to
make in cc-mode.el and c-ts-mode.el, this will be possible.

So Emacs 30 will not regress from Emacs 29, and will make the
situation at least a tad better.

> > I don't think the current mechanism is ready for the release of Emacs 30.
> 
> I don't see a regression here.

Right, and so no obstacles for releasing Emacs 30, once we make the
proposed changes in cc-mode.el and in c-ts-mode.el, which rectify the
tweaking of major-mode-remap-defaults.

> > What I think we're lacking is an explicit setting or command for the
> > user to state what her preferred mode for C actually is.

Yes, and we should work on adding that.  But this will not happen in
Emacs 30, especially since we don't yet have a clear idea how to do
this.

Alan, please help us release Emacs 30 sooner rather than later by
agreeing to the proposed changes in cc-mode.el and in c-ts-mode.el.

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

[Eli Zaretskii]

> Date: Fri, 15 Nov 2024 19:46:03 +0000
> Cc: Eli Zaretskii <eliz@gnu.org>, 74339@debbugs.gnu.org, acm@muc.de
> From: Alan Mackenzie <acm@muc.de>
> 
> So, for a user trying out Emacs 30, with a desktop file containing at
> least one file with major mode c-ts-mode; visiting a file with the above
> Local Variables section will indeed start the buffer with C Mode?

No, it will turn on the mode specified in the desktop file.  And it is
not necessarily wrong: desktop.el restores the session as it was
before Emacs was shut down, so using the same major mode might be
exactly what the user expect.  (It could also be against user
expectations, which is why I think we need a user option to let users
control what desktop.el does in this case.)

> I haven't looked just yet, but can I assume there's a recipe in the
> Emacs 30 NEWS file telling users how to switch between old behaviour
> (-*- c -*- always means C mode) and new behaviour (-*- c -*- can mean
> c-ts-mode depending on other settings)?

There is now.

> Is the default to keep the old behaviour, as is customary with new
> features in Emacs?

Yes, as long as c-ts-mode was not loaded.  People who don't want to
depend on remapping caused by loading features or packages should
customize major-mode-remap-alist to express their preferences.

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: Fri, 15 Nov 2024 15:45:46 -0500
> 
> > Here is a section of a test file sent to bug-cc-mode some while ago:
> >
> > /*
> > ** Local Variables:
> > ** mode:c
> > ** indent-tabs-mode:nil
> > ** c-basic-offset:4
> > ** End:
> > */
> >
> > Here it is evident that by "mode:c" the OP means C Mode, not whatever
> > random mode happens to have taken the symbol `c-mode'.
> 
> It is evident that the OP means CC-mode's C Mode because the bug report
> is sent to `bug-cc-mode`, indeed.

Perhaps we should introduce (on master) a boolean variable to disable
mode remapping?  Then files which want to force a mode could specify
that.

> >> If you really insist, we can add
> >>     (add-to-list 'major-mode-remap-defaults '(c-ts-mode . c-mode))
> >>     (add-to-list 'major-mode-remap-defaults '(c++-ts-mode . c++-mode))
> >> to your `cc-mode.el` together with corresponding removals in
> >> `c-ts-mode.el`, even though in my book file-local settings of
> >> `mode: c-ts-mode` in non-personal files are just bugs.
> > The problem is that entries in major-mode-remap-defaults (and the other
> > one) do not accurately represent user preferences.
> 
> Entries in `major-mode-remap-defaults` indeed do not reflect
> a user preference, just a "circumstantial" preference.
> 
> [ Ideally, they shouldn't be set just by loading a file (whether
>   `cc-mode.el` or `c-ts-mode.el`).  But after a long protracted
>   discussion the Emacs maintainers decided that it was the least bad
>   choice in Emacs-29.  This may be revisited in the future, e.g. for
>   Emacs-31, but AFAICT it's too late to make such a change in
>   Emacs-30.  ]

yes, it's too late to change this for Emacs 30.  So Emacs 30 will make
only a half-step in this direction.

> But entries in `major-mode-remap-alist` very much reflect a user preference.

Yes.  I have now added to the Emacs user manual explicit advice to
customize that to express user's firm preferences that override any
"internally-motivated" mode remapping.

> > I haven't looked just yet, but can I assume there's a recipe in the
> > Emacs 30 NEWS file telling users how to switch between old behaviour
> > (-*- c -*- always means C mode) and new behaviour (-*- c -*- can mean
> > c-ts-mode depending on other settings)?
> 
> If anything, Emacs-30 makes it easier than Emacs-29:
> 
>     (add-to-list 'major-mode-remap-alist '(c-mode))

This is now in NEWS and in the manual.

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

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Fri, 15 Nov 2024 19:22:47 -0800
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, Eli Zaretskii <eliz@gnu.org>, 74339@debbugs.gnu.org
> 
> Alan Mackenzie <acm@muc.de> writes:
> 
> > That "somehow" is the loading of c-ts-mode.  I think that even C-h f
> > c-ts-mode counts as an "explicit indication" of a supposed preference for
> > c-ts-mode, given that it loads c-ts-mode (if it actually does).
> 
> It seems like you're right about that, in emacs -Q.
> 
> FWIW, I consider that less than ideal, and would prefer that we did that
> only when enabling the mode.  Loading files shouldn't change behaviour,
> exactly for this reason.  So I'd be in favor of making such a change (on
> master).  But that's me.

If we are discussing changes on master (which is not the subject of
this bug report), then turning on a mode is not necessarily a reliable
sign of the user preferences.  The simplest example is when a user
turns on the mode in a single buffer, for whatever reasons.

I think we need special-purpose commands to express global user
preferences regarding which mode to use for a certain file type.
However, this is for |Emacs 31, and should be discussed separately.

> >> I'd use that setting, if I ever ran into any files with a "-*- c-ts -*-"
> >> cookie.  Similarly, I expect that c-ts-mode users will want to use
> >> c-ts-mode precisely when a file has a "-*- c -*-" cookie.
> >
> > We don't have fine enough control.  /* mode: c */ followed by /*
> > c-basic-offset: 4 */ in the Local Variables: section is a sure sign that
> > C Mode is intended, not a random C handling mode.
> >
> > What I think we're lacking is an explicit setting or command for the user
> > to state what her preferred mode for C actually is.
> > major-mode-remap-alist isn't that setting - it's too involved, too
> > awkward, and it talks about "remappinig modes" (its internal mechanism)
> > rather than the user's preferred Mode for C.
> 
> I think `major-mode-remap-alist` is the explicit setting that we have.
> That said, I wouldn't personally close the door to a proposal that is
> significantly better.  I'm just not sure what it would look like.
> 
> > What we need is a defcustom 3-valued radio-button defaulting to "no
> > explicit preference", and having other values "c-mode" and
> > "c-ts-mode".
> 
> The benefit of `major-mode-remap` is that it's sufficiently general not
> just for c-mode/c-ts-mode, but for all other cases where we have two or
> more modes, such as yaml-mode/yaml-ts-mode, etc.  And it will handle
> whatever new modes we can dream up in the future.
> 
> It also fits in nicely with the equally general `auto-mode-alist`,
> `interpreter-mode-alist`, etc., that we already have.
> 
> For these reasons, I think I prefer `major-mode-remap` to a specific
> option just for c-mode/c-ts-mode.

Having an option that is specific to C mode is definitely not the best
idea.  We should have a more general mechanism for users to express
their preferences, which are at the same time more convenient and
easy-to-use than customizing major-mode-remap-alist, and perhaps also
allow more selective remapping, like only when a file has no mode
cookie.

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

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  74339@debbugs.gnu.org
>> Date: Fri, 15 Nov 2024 15:45:46 -0500
>>
>> > Here it is evident that by "mode:c" the OP means C Mode, not whatever
>> > random mode happens to have taken the symbol `c-mode'.
>>
>> It is evident that the OP means CC-mode's C Mode because the bug report
>> is sent to `bug-cc-mode`, indeed.
>
> Perhaps we should introduce (on master) a boolean variable to disable
> mode remapping?  Then files which want to force a mode could specify
> that.

I'm not sure what is the use case for something like that.
Do we want files to be able to override user preferences?

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

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Sat, 16 Nov 2024 06:03:14 -0800
> Cc: acm@muc.de, 74339@debbugs.gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Stefan Monnier <monnier@iro.umontreal.ca>
> >> Cc: Eli Zaretskii <eliz@gnu.org>,  74339@debbugs.gnu.org
> >> Date: Fri, 15 Nov 2024 15:45:46 -0500
> >>
> >> > Here it is evident that by "mode:c" the OP means C Mode, not whatever
> >> > random mode happens to have taken the symbol `c-mode'.
> >>
> >> It is evident that the OP means CC-mode's C Mode because the bug report
> >> is sent to `bug-cc-mode`, indeed.
> >
> > Perhaps we should introduce (on master) a boolean variable to disable
> > mode remapping?  Then files which want to force a mode could specify
> > that.
> 
> I'm not sure what is the use case for something like that.
> Do we want files to be able to override user preferences?

The case of CC Mode bug report above might be one such example.

A (hypothetical) tutorial for using CC Mode (e.g., teaching about its
interactive indentation customization feature) might be another.

It isn't supposed to be a frequent situation, but when it happens, why
not allow it to be supported?

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

[Alan Mackenzie]

Hello, Stefan.

On Fri, Nov 15, 2024 at 19:22:47 -0800, Stefan Kangas wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > That "somehow" is the loading of c-ts-mode.  I think that even C-h f
> > c-ts-mode counts as an "explicit indication" of a supposed preference for
> > c-ts-mode, given that it loads c-ts-mode (if it actually does).

> It seems like you're right about that, in emacs -Q.

> FWIW, I consider that less than ideal, and would prefer that we did that
> only when enabling the mode.  Loading files shouldn't change behaviour,
> exactly for this reason.  So I'd be in favor of making such a change (on
> master).  But that's me.

We could perhaps talk about this again after the release of Emacs 30.

> > I don't think the current mechanism is ready for the release of Emacs 30.
> > It hasn't been thought through thoroughly.

> I see no release blocker at this late stage, myself.

> >> I'd use that setting, if I ever ran into any files with a "-*- c-ts -*-"
> >> cookie.  Similarly, I expect that c-ts-mode users will want to use
> >> c-ts-mode precisely when a file has a "-*- c -*-" cookie.

> > We don't have fine enough control.  /* mode: c */ followed by /*
> > c-basic-offset: 4 */ in the Local Variables: section is a sure sign that
> > C Mode is intended, not a random C handling mode.

> > What I think we're lacking is an explicit setting or command for the user
> > to state what her preferred mode for C actually is.
> > major-mode-remap-alist isn't that setting - it's too involved, too
> > awkward, and it talks about "remappinig modes" (its internal mechanism)
> > rather than the user's preferred Mode for C.

> I think `major-mode-remap-alist` is the explicit setting that we have.
> That said, I wouldn't personally close the door to a proposal that is
> significantly better.  I'm just not sure what it would look like.

> > What we need is a defcustom 3-valued radio-button defaulting to "no
> > explicit preference", and having other values "c-mode" and
> > "c-ts-mode".

> The benefit of `major-mode-remap` is that it's sufficiently general not
> just for c-mode/c-ts-mode, but for all other cases where we have two or
> more modes, such as yaml-mode/yaml-ts-mode, etc.  And it will handle
> whatever new modes we can dream up in the future.

> It also fits in nicely with the equally general `auto-mode-alist`,
> `interpreter-mode-alist`, etc., that we already have.

> For these reasons, I think I prefer `major-mode-remap` to a specific
> option just for c-mode/c-ts-mode.

I was thinking more of a macro which would create the option mechanism
for any such mode, and which wouldn't have to make a user consider
"remapping".

> >> Again, being able to do that is exactly the point of major-mode-remap.
> >> I struggle to understand why that flexibility is controversial.  It
> >> puts more power into users' hands, that's all.

> > It involves c-ts-mode purloining CC Mode's symbols for its own use.  If a
> > user wishes to use major-mode-remap-alist for that, that's one thing -
> > having it done by default in major-mode-remap-defaults by Emacs is
> > something quite different, which I think is unacceptable.

> So you don't like the specific detail that it overloads the use of the
> symbol `c-mode` as a proxy for saying C files?

Indeed not.  It weakens the prime purpose of those names, which is to
identify and call those modes in CC Mode.  Should `c-mode' get the
meaning "any old mode which handles C", then there will be no unambiguous
way for an elisp programmer to refer to c-mode.  c-mode has no other
name, and nobody has suggested giving it one.  Names are important, and
have power.  If somebody used "Stefan Kangas" to refer to some other
person, you would not like it either.

> FWIW, and AFAIR, I think we discussed this overloading of the mode name
> on the list, and the other option ....

_One_ other option.  There were presumably several.

> .... was to introduce a new concept of "languages" into Emacs Lisp,
> where we would have had alist entries like `(c . c-mode)` instead.  The
> conclusion was that doing that would be more complex and it was hard to
> justify this complication.  I can't remember that any other ways to
> avoid this overloading were suggested.

Had I been invited to this discussion, I would certainly have suggested
some other way(s), as I have done recently in this thread.  The current
discussion would then not need to have taken place.

Could you give me some coordinates for the discussion, please?  Back in
May, when I committed the patch that has proven so unpopular, I searched
for such a discussion, but couldn't find it.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Andrea Corallo]

Alan Mackenzie <acm@muc.de> writes:

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

Hello Alan,

pushing controversial commits in our repository to spark discussion is
not the right use of emacs.git, also this is not the behaviour what we
expect from developers with write access to our repo.  Please take this
in account for the future.

Thanks

  Andrea

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

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Thu, 14 Nov 2024 11:24:32 +0200
>> Cc: monnier@iro.umontreal.ca, 74339@debbugs.gnu.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>> 

[...] 

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

+1

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

[Alan Mackenzie]

Hello, Eli.

On Sat, Nov 16, 2024 at 18:49:15 +0200, Eli Zaretskii wrote:
> > Date: Sat, 16 Nov 2024 15:40:24 +0000
> > Cc: acm@muc.de
> > From: Alan Mackenzie <acm@muc.de>

> > > Alan, please help us release Emacs 30 sooner rather than later by
> > > agreeing to the proposed changes in cc-mode.el and in c-ts-mode.el.

> > I don't and can't agree to these changes as they're currently proposed.
> > My concerns expressed over the last few days haven't been addressed;
> > they've merely been dismissed.  In effect, you're proposing just
> > reverting my patch from May, without addressing the reasons for that
> > patch.

> No, not to revert: to amend it in relatively minor ways.

No.  Nullifying it's main purpose and leaving only a toothless hulk is
not relatively minor.  The purpose of the patch was to protect CC Mode's
symbols.  It had unfortunate side effects, hence this bug.

> Specifically, I'm asking not to add these entries to
> 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))

> Instead, _remove_ them from the list (if they are in the list).  The
> rest, i.e. adding the elements that "remap" c-mode to itself, viz.:

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

> Can and should stay.  (Btw, it is better to use assq-delete-all,
> because the above removes only the instances of the first element for
> each mode that it finds in the list.  Btw, doing so will also avoid
> the need to add the 3 entries above, AFAIU.)

Can you perhaps suggest another way of protecting CC Mode's symbols in
place of the patch which is to be amended/removed?

> > I have proposed two ways of fixing the immediate problem, both of them
> > simple, easy to review, and easy to test.  You have rejected them both.
> > It seems it is more important to release Emacs 30 soon that to get it
> > right.

> We cannot always set everything right when the release is close.  What
> is being proposed to fix this issue will make things a little bit
> better than they were in Emacs 29, and certainly no worse.  We will
> need to try to find better solutions in Emacs 31.

> By contrast the solutions you proposed are much more risky, as they
> touch areas that are not directly related to the code which caused the
> issue at hand, and because they will have a broader effect.  They are
> therefore inappropriate for a release branch that is in its 2nd
> pretest.

Why MUCH more risky?  They're a little bit more risky, perhaps.  In the
time we've been discussing the matter, one of them could have been
implemented and now be under review/test.

For that matter, the amended patch you're proposing hasn't really been
tested either.  We know that nobody looked at it or tried it out in the
5½ months from the commit, up until when you looked at it and raised the
bug.  But we know this patch will have bad effects (see the rest of my
posts in this thread).

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Eli Zaretskii]

> Date: Sat, 16 Nov 2024 21:56:03 +0000
> Cc: 74339@debbugs.gnu.org, acm@muc.de
> From: Alan Mackenzie <acm@muc.de>
> 
> > > I don't and can't agree to these changes as they're currently proposed.
> > > My concerns expressed over the last few days haven't been addressed;
> > > they've merely been dismissed.  In effect, you're proposing just
> > > reverting my patch from May, without addressing the reasons for that
> > > patch.
> 
> > No, not to revert: to amend it in relatively minor ways.
> 
> No.  Nullifying it's main purpose and leaving only a toothless hulk is
> not relatively minor.  The purpose of the patch was to protect CC Mode's
> symbols.  It had unfortunate side effects, hence this bug.

What kind of protection did you have in mind, and how does the current
code in cc-mode provide that protection?

> > Specifically, I'm asking not to add these entries to
> > 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))
> 
> > Instead, _remove_ them from the list (if they are in the list).  The
> > rest, i.e. adding the elements that "remap" c-mode to itself, viz.:
> 
> >     (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))))
> 
> > Can and should stay.  (Btw, it is better to use assq-delete-all,
> > because the above removes only the instances of the first element for
> > each mode that it finds in the list.  Btw, doing so will also avoid
> > the need to add the 3 entries above, AFAIU.)
> 
> Can you perhaps suggest another way of protecting CC Mode's symbols in
> place of the patch which is to be amended/removed?

I need to understand what you mean by "protection of symbols" before I
can suggest anything.

> > > I have proposed two ways of fixing the immediate problem, both of them
> > > simple, easy to review, and easy to test.  You have rejected them both.
> > > It seems it is more important to release Emacs 30 soon that to get it
> > > right.
> 
> > We cannot always set everything right when the release is close.  What
> > is being proposed to fix this issue will make things a little bit
> > better than they were in Emacs 29, and certainly no worse.  We will
> > need to try to find better solutions in Emacs 31.
> 
> > By contrast the solutions you proposed are much more risky, as they
> > touch areas that are not directly related to the code which caused the
> > issue at hand, and because they will have a broader effect.  They are
> > therefore inappropriate for a release branch that is in its 2nd
> > pretest.
> 
> Why MUCH more risky?  They're a little bit more risky, perhaps.

Let's agree that they are "more risky".

> In the time we've been discussing the matter, one of them could have
> been implemented and now be under review/test.

The problem is not with the time it takes to implement a solution, the
problem is with the time it will take to verify it doesn't have any
unintended consequences and doesn't cause regressions elsewhere.  With
the changes I proposed, the probability of such adverse effects is
very low, because the changes are local to the code whose effect we
now understand well enough, having discussed it here so extensively.
By contrast, the other proposals modify other parts of Emacs, and thus
their effect is less certain.  Which means they will delay the
release.

> For that matter, the amended patch you're proposing hasn't really been
> tested either.

It's a minor change in code whose effect is now understood very well.
And I did test something very similar in my sessions, once I
discovered the issue and understood what causes it.

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

[Eli Zaretskii]

> Cc: monnier@iro.umontreal.ca, 74339@debbugs.gnu.org
> Date: Thu, 14 Nov 2024 21:23:41 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> 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.

I've now made changes in c-ts-mode.el on the emacs-30 branch that
allow to remap CC Mode's C/C++ modes to the corresponding tree-sitter
based modes as result of loading c-ts-mode, which resolves this bug.
(cc-mode.el remains unchanged, so loading cc-mode will revert to using
CC Mode, as it did before this change.  IOW, the changes I installed
make it possible for users to prefer c-ts-mode if they want, and leave
intact the ability of users to prefer cc-mode if that is what they
want.)

With that, I'm closing this bug.

Dmitry, please consider a similar change in ruby-mode.el and
ruby-ts-mode.el, since what we have there now is that once
ruby-ts-mode is loaded, there's no way for users to go back to using
ruby-mode unless they customize major-mode-remap-alist.

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

[Alan Mackenzie]

Hello, Eli.

On Thu, Nov 21, 2024 at 09:57:00 +0200, Eli Zaretskii wrote:
> > Cc: monnier@iro.umontreal.ca, 74339@debbugs.gnu.org
> > Date: Thu, 14 Nov 2024 21:23:41 +0200
> > From: Eli Zaretskii <eliz@gnu.org>

[ .... ]

> I've now made changes in c-ts-mode.el on the emacs-30 branch that
> allow to remap CC Mode's C/C++ modes to the corresponding tree-sitter
> based modes as result of loading c-ts-mode, which resolves this bug.
> (cc-mode.el remains unchanged, so loading cc-mode will revert to using
> CC Mode, as it did before this change.  IOW, the changes I installed
> make it possible for users to prefer c-ts-mode if they want, and leave
> intact the ability of users to prefer cc-mode if that is what they
> want.)

> With that, I'm closing this bug.

Thanks for the info!  I'm glad the bug is finally closed.

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Dmitry Gutov]

On 21/11/2024 09:57, Eli Zaretskii wrote:
> Dmitry, please consider a similar change in ruby-mode.el and
> ruby-ts-mode.el, since what we have there now is that once
> ruby-ts-mode is loaded, there's no way for users to go back to using
> ruby-mode unless they customize major-mode-remap-alist.

Could you please go ahead with whatever changes you think appropriate?

I didn't do (or review) either of the previous changes in that area.

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

[Eli Zaretskii]

> Date: Thu, 21 Nov 2024 21:02:55 +0200
> Cc: 74339-done@debbugs.gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 21/11/2024 09:57, Eli Zaretskii wrote:
> > Dmitry, please consider a similar change in ruby-mode.el and
> > ruby-ts-mode.el, since what we have there now is that once
> > ruby-ts-mode is loaded, there's no way for users to go back to using
> > ruby-mode unless they customize major-mode-remap-alist.
> 
> Could you please go ahead with whatever changes you think appropriate?
> 
> I didn't do (or review) either of the previous changes in that area.

I could suggest a patch, but as I don't use Ruby modes, I'd hesitate
to install it without an okay from someone who does.