bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes

[Eli Zaretskii <eliz@gnu.org>]

> From: Yuan Fu <casouri@gmail.com>
> Date: Sat, 20 Jan 2024 16:32:02 -0800
> Cc: Eli Zaretskii <eliz@gnu.org>,
>  Stefan Monnier <monnier@iro.umontreal.ca>,
>  Dmitry Gutov <dmitry@gutov.dev>,
>  Stefan Kangas <stefankangas@gmail.com>,
>  68246@debbugs.gnu.org
> 
> IIUC Stefan’s patch is trying to use xxx-mode to represent “mode for xxx in general”, sort of like the keys in major-mode-remap-alist. And IIUC Joao and Dmitry are not very comfortable with it because (mode-A R mode-B) where R is derived-mode-p implicitly means mode-B runs mode-A’s hooks and major mode body, and this patch would break that, which would bring a lot of confusion.

There should be no confusion.  derived-mode-add-parents is documented
regarding the effects and meaning (and if the current documentation is
not clear enough, we can clarify it further).

Moreover, I see no reason to assume FOO-mode runs any mode hook except
FOO-mode-hook.

> Instead of using xxx-mode, can we set common-xxx-mode to the parent of both xxx-mode and xxx-ts-mode? Or maybe abtract-xxx-mode, or just xxx, the name doesn’t matter. The point is this is just a symbol and doesn’t have hooks and other implicit things a major mode have. It’s still a bit confusing, but it should be less confusing. We can also add a variable common-mode-list or abstract-mode-list so these symbols don’t seem to come out of nowhere.

I'm firmly against introducing modes that are not real modes.  We do
use base-modes where it makes sense, but if such a mode makes no
sense, introducing it as a means to some end is just going to make
things more confusing.

Once again: let's have real practical issues on our hands before we
look for solutions.  Right now, no such issues are known, since the
changes barely landed on master.  There's no reason for looking for
hasty solutions for problems we don't have a good handle on.