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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 16 Nov 2024 21:56:03 +0000
> Cc: 74339@debbugs.gnu.org, acm@muc.de
> From: Alan Mackenzie <acm@muc.de>
> 
> > > I don't and can't agree to these changes as they're currently proposed.
> > > My concerns expressed over the last few days haven't been addressed;
> > > they've merely been dismissed.  In effect, you're proposing just
> > > reverting my patch from May, without addressing the reasons for that
> > > patch.
> 
> > No, not to revert: to amend it in relatively minor ways.
> 
> No.  Nullifying it's main purpose and leaving only a toothless hulk is
> not relatively minor.  The purpose of the patch was to protect CC Mode's
> symbols.  It had unfortunate side effects, hence this bug.

What kind of protection did you have in mind, and how does the current
code in cc-mode provide that protection?

> > Specifically, I'm asking not to add these entries to
> > major-mode-remap-defaults:
> 
> >   (add-to-list 'major-mode-remap-defaults '(c++-mode . c++-ts-mode))
> >   (add-to-list 'major-mode-remap-defaults '(c-mode . c-ts-mode))
> >   (add-to-list 'major-mode-remap-defaults '(c-or-c++-mode . c-or-c++-ts-mode))
> 
> > Instead, _remove_ them from the list (if they are in the list).  The
> > rest, i.e. adding the elements that "remap" c-mode to itself, viz.:
> 
> >     (dolist (mode '(c-mode c++-mode c-or-c++-mode))
> >       (if (and (setq entry (assq mode major-mode-remap-defaults))
> > 	       (null (cdr entry)))
> > 	  (setq major-mode-remap-defaults
> > 		(delq entry major-mode-remap-defaults)))
> >       (push (cons mode nil) major-mode-remap-defaults))))
> 
> > Can and should stay.  (Btw, it is better to use assq-delete-all,
> > because the above removes only the instances of the first element for
> > each mode that it finds in the list.  Btw, doing so will also avoid
> > the need to add the 3 entries above, AFAIU.)
> 
> Can you perhaps suggest another way of protecting CC Mode's symbols in
> place of the patch which is to be amended/removed?

I need to understand what you mean by "protection of symbols" before I
can suggest anything.

> > > I have proposed two ways of fixing the immediate problem, both of them
> > > simple, easy to review, and easy to test.  You have rejected them both.
> > > It seems it is more important to release Emacs 30 soon that to get it
> > > right.
> 
> > We cannot always set everything right when the release is close.  What
> > is being proposed to fix this issue will make things a little bit
> > better than they were in Emacs 29, and certainly no worse.  We will
> > need to try to find better solutions in Emacs 31.
> 
> > By contrast the solutions you proposed are much more risky, as they
> > touch areas that are not directly related to the code which caused the
> > issue at hand, and because they will have a broader effect.  They are
> > therefore inappropriate for a release branch that is in its 2nd
> > pretest.
> 
> Why MUCH more risky?  They're a little bit more risky, perhaps.

Let's agree that they are "more risky".

> In the time we've been discussing the matter, one of them could have
> been implemented and now be under review/test.

The problem is not with the time it takes to implement a solution, the
problem is with the time it will take to verify it doesn't have any
unintended consequences and doesn't cause regressions elsewhere.  With
the changes I proposed, the probability of such adverse effects is
very low, because the changes are local to the code whose effect we
now understand well enough, having discussed it here so extensively.
By contrast, the other proposals modify other parts of Emacs, and thus
their effect is less certain.  Which means they will delay the
release.

> For that matter, the amended patch you're proposing hasn't really been
> tested either.

It's a minor change in code whose effect is now understood very well.
And I did test something very similar in my sessions, once I
discovered the issue and understood what causes it.