bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alan Mackenzie
Subject: bug#74339: 30.0.92; CC Mode stomps C TS Mode
Date: Fri, 15 Nov 2024 21:56:03 +0000

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]