GNU bug report logs - #68246
30.0.50; Add non-TS mode as extra parent of TS modes

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 68246 <at> debbugs.gnu.org, casouri <at> gmail.com, joaotavora <at> gmail.com, monnier <at> iro.umontreal.ca, stefankangas <at> gmail.com
Subject: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes
Date: Mon, 15 Jan 2024 20:32:27 +0200

On 15/01/2024 14:46, Eli Zaretskii wrote:
>> Date: Mon, 15 Jan 2024 04:10:16 +0200
>> Cc: 68246 <at> debbugs.gnu.org, casouri <at> gmail.com, monnier <at> iro.umontreal.ca
>> From: Dmitry Gutov <dmitry <at> 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...

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.