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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 15 Jan 2024 20:32:27 +0200
> Cc: joaotavora@gmail.com, stefankangas@gmail.com, 68246@debbugs.gnu.org,
>  casouri@gmail.com, monnier@iro.umontreal.ca
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> >>> Those users will hopefully submit bug reports or otherwise complain on
> >>> the Emacs mailing lists, and then we will know.
> >>
> >> I rather wouldn't rely on that.
> > 
> > Why not?  The decisions we made are not arbitrary.  Given the best
> > consensus (or lack thereof) we could arrive upon after careful
> > consideration of the issues, it is perfectly fine to expect feedback
> > to set us straight if we made a mistake.
> 
> Because the corresponding downsides are already known.

And so are the advantages.  And from where I stand, the advantages
outweigh the known downsides.

> They are not catastrophic ones, however, and as such they won't be
> critical in day-to-day usage (prompting fewer users to bother with
> bug reports).

Once again: we should try the simpler, light-weight solution before we
go to more complex ones.

> And if one builds a chair with 5 legs

We don't build a chair with 5 legs, so the analogy misses the point.

> Nor we are quick to change our mind based on such feedback, as bug#61177 
> and bug#61177 demonstrate.

We are as quick as possible.  You are welcome to step up as an Emacs
maintainer and improve these aspects if you can.

> >>> The recommendation is to use base modes where it makes sense, and the
> >>> installed changes around derived-mode-add-parents don't in any way
> >>> preclude having a base mode and don't make it harder.  But I don't
> >>> think we should force everyone in this situation to invent a base mode
> >>> as the sole means for solving this.
> >>
> >> It's not like we don't have an existing solution for this: if there are
> >> two different modes to configure, change the settings for both modes, or
> >> alter two hooks.
> > 
> > This doesn't solve the problem at hand, since the differences between
> > the modes are not limited to these simple aspects.
> 
> I don't understand your response.

Then you will have to re-read all the discussions which led to
separate modes, and re-discover the problems we discovered almost a
year ago.  The current arrangement was not an accident and not
happened by default.  It is the best arrangement we could come up with
given the differences between the TS and non-TS modes.  Where the
differences are relatively small, we either have a significant base
mode or something similar.  But in several important cases that is
impractical, so we don't.

> The original description says:
> 
>    packages tend to behave poorly because they do not understand that a
>    buffer in `js-ts-mode` contains Javascript

A major mode doesn't need to "understand" anything, it needs to
support users as the users expect.

> >> Here's a draft patch of how a "language" could work. It doesn't alter
> >> every entry, but it is backward compatible.
> > 
> > Like I said: it is heavier, so we should only do that if the simpler
> > method don't work well enough.  So thanks, but let's try the existing
> > simpler solution first and see if we need something better.
> 
> Indeed it's heavier because it's not just a fix, but a whole new 
> feature. I suggest people try it out and see how they like it.

I think such a feature is unjustified by what we know about the
problem.  If we don't know enough, we will learn soon enough, and will
then be in a position to make informed decisions, unlike now that we
are arguing about issues we don't yet have enough experience about to
be able to discuss usefully and effectively.