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

[Dmitry Gutov <dmitry@gutov.dev>]

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