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

Previous Next

Full log

Message #170 received at 74339 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: acm <at> muc.de, monnier <at> iro.umontreal.ca, 74339 <at> debbugs.gnu.org
Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode
Date: Sat, 16 Nov 2024 13:45:45 +0200

> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Fri, 15 Nov 2024 19:22:47 -0800
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, Eli Zaretskii <eliz <at> gnu.org>, 74339 <at> debbugs.gnu.org
> 
> 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.

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.

Previous Next

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