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

[Dmitry Gutov]

On 15/01/2024 14:46, Eli Zaretskii wrote:
> > Date: Mon, 15 Jan 2024 04:10:16 +0200
> > Cc: 68246@debbugs.gnu.org, casouri@gmail.com, monnier@iro.umontreal.ca
> > From: Dmitry Gutov <dmitry@gutov.dev>
> >
> > > > However it is not easy to quantify confused users looking to understand
> > > > the new meaning of things in dir-locals.el.  Or users wondering why they
> > > > need to set Eglot variables in both 'c++-mode-hook' and
> > > > 'c++-ts-mode-hook' when all they see is 'c++-mode' in
> > > > 'eglot-server-programs'.
> > >
> > > 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. 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).

And if one builds a chair with 5 legs, it will likely be not as 
convenient to use, but not many people will go and tell the author that 
the chair has an extra leg - it's obviously intentional.

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

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

The original description says:

  packages tend to behave poorly because they do not understand that a
  buffer in `js-ts-mode` contains Javascript

Presumably, a call like (derived-mode-p 'js-mode) fails. The packages 
can change it to (derived-mode-p '(js-mode js-ts-mode)), and it will 
succeed. Yes, it's a bit more work, but they will have to do it anyway 
to support Emacs 29.1 for a number of years.

> Less magical and more verbose, but being explicit can
> > be good.
> >
> > > > 2. Explicitly associating some major modes with languages or file types.
> > > >      This doesn't seem hard and other further uses like suggesting modes
> > > >      or packages to a new user based on languages have been proposed.
> > >
> > > This is IMO a heavier and more thorough change, especially since Emacs
> > > doesn't have the notion of "language".  This discussion shows that its
> > > advantages are not evident, and moreover we don't even have a clear
> > > shared view what will that entail.
> >
> > 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.

If not, well...