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

[Dmitry Gutov <dmitry@gutov.dev>]

On 15/01/2024 20:52, Eli Zaretskii wrote:

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

A change in inheritance chain is a pretty heavy/complex solution in my book.

>> And if one builds a chair with 5 legs
> 
> We don't build a chair with 5 legs, so the analogy misses the point.

When a certain behavior is obviously intended, you don't always report 
is as a bug. Sometimes you sigh deeply and either continue using the tool,

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

I didn't mean that the speed was the issue here. The bugs above are 
closed as "wontfix", rather than remaining in-progress.

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

Perhaps I should clarify that my preferred alternative solution is not 
base modes, but "keep things as is". The same current arrangement you 
mention.

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

I would be best to address the technical approach I mentioned rather 
than pick at the phrasing in a sentence that doesn't belong to me.

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

It doesn't seem to me like that experiment is easy to reverse.

And I'm not sure what is unclear about the problem, to require 
additional data.