GNU bug report logs - #74339
30.0.92; CC Mode stomps C TS Mode

Previous Next

Full log

View this message in rfc822 format

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Alan Mackenzie <acm <at> muc.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>, 74339 <at> debbugs.gnu.org
Subject: bug#74339: 30.0.92; CC Mode stomps C TS Mode
Date: Fri, 15 Nov 2024 19:22:47 -0800

Alan Mackenzie <acm <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.