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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  74339@debbugs.gnu.org
> Date: Thu, 14 Nov 2024 12:29:49 -0500
> 
> Not quite: `auto-mode-alist` should always map `.c` files to `c-mode`.

Why "always"?

> The choice between `c-mode` and `c-ts-mode` should be made
> via `major-mode-remap-*`.

That's one implementation, but it isn't the only one, and I'm not sure
it is the best one.

> That's what those vars are for.

major-mode-remap-alist is for remapping major modes in general, for
whatever reasons.  The non-TS vs TS modes is just one case where it
can be used, but it is not the only one, and maybe not even the most
important one.

> So loading either mode should not change `auto-mode-alist`.

It doesn't have to be due to loading the mode, it could be due to the
user flipping some option.  auto-mode-alist could stay the same, but
the result of looking up the proper mode for a .c file will be
different, depending on such a user option.

> IIUC the proposal to use the "last loaded" mode would be obtained, by
> making the two files set `major-mode-remap-defaults` accordingly.
> `c-ts-mode.el` already does that, so all we need is to change
> `cc-mode.el` so it puts itself first but doesn't prevent `c-ts-mode.el`
> from putting itself first in the future (contrary to what it currently
> does).

I think both files should first remove the existing elements that
remap c-mode and c++-mode.  Otherwise add-to-list will do nothing.

> The patch I sent earlier should do just that (by removing the entries
> added by `c-ts-mode.el` rather than by adding entries, so as to avoid
> growing `major-mode-remap-defaults` unnecessarily).

This is not enough, I think.  What will happen if, by some
happenstance, major-mode-remap-defaults has both elements added by
cc-mode and those added by c-ts-mode?