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

[Andrea Corallo <acorallo@gnu.org>]

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