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

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Sat, Nov 16, 2024 at 18:49:15 +0200, Eli Zaretskii wrote:
> > Date: Sat, 16 Nov 2024 15:40:24 +0000
> > Cc: acm@muc.de
> > From: Alan Mackenzie <acm@muc.de>

> > > Alan, please help us release Emacs 30 sooner rather than later by
> > > agreeing to the proposed changes in cc-mode.el and in c-ts-mode.el.

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

> 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 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.  In the
time we've been discussing the matter, one of them could have been
implemented and now be under review/test.

For that matter, the amended patch you're proposing hasn't really been
tested either.  We know that nobody looked at it or tried it out in the
5½ months from the commit, up until when you looked at it and raised the
bug.  But we know this patch will have bad effects (see the rest of my
posts in this thread).

-- 
Alan Mackenzie (Nuremberg, Germany).