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