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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 8 Jan 2024 22:06:56 +0200
> Cc: monnier@iro.umontreal.ca, 68246@debbugs.gnu.org, casouri@gmail.com,
>  joaotavora@gmail.com
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 08/01/2024 21:55, Eli Zaretskii wrote:
> >> Date: Mon, 8 Jan 2024 20:57:13 +0200
> >> Cc:68246@debbugs.gnu.org,casouri@gmail.com,joaotavora@gmail.com
> >> From: Dmitry Gutov<dmitry@gutov.dev>
> >>
> >> Even if we call non-file-visiting buffers' contents "languages", I don't
> >> think anyone will have a heart attack or something.
> > "No heart attack" is a poor criterion for good parameterization and
> > consistent terminology.  Confusing terms will spread confusion and
> > bugs.  There's no reason for us to settle for sub-optimal terminology.
> > 
> >> E.g., for example, we have message-mode, but if we wanted to support
> >> alternatives, we could call the base "email-message". Or for different
> >> major modes to edit VC commit messages, we could call the language
> >> "vc-log-message".
> > Those are not "languages", so let's not call them that.
> 
> I'm not married to the term (have there been alternatives suggested?), 
> but I do believe that having a notion distinct from "major modes" would 
> bring more clarity in this area.

If we can come up with some sane terminology, let's do that.  But
adopting incorrect one just because we need some name is not TRT.