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

Previous Next

Full log

Message #283 received at 68246 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>, João Távora
 <joaotavora <at> gmail.com>, Stefan Kangas <stefankangas <at> gmail.com>
Cc: 68246 <at> debbugs.gnu.org, casouri <at> gmail.com, monnier <at> iro.umontreal.ca
Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes
Date: Mon, 15 Jan 2024 04:10:16 +0200

[Message part 1 (text/plain, inline)]

On 14/01/2024 09:02, Eli Zaretskii wrote:
>> From: João Távora <joaotavora <at> gmail.com>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>,  Stefan Monnier
>>   <monnier <at> iro.umontreal.ca>,  68246 <at> debbugs.gnu.org
>> Date: Sun, 14 Jan 2024 03:10:02 +0000
>>
>> Yuan Fu <casouri <at> gmail.com> writes:
>>
>>> observe what breaks? Then Joao can either say “I told you” or happily
>>> found out that this patch works ok.
>>
>> Those are not the only two outcomes.  It might work OK and not break
>> anything [*].
>>
>> 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.

>> There are better alternatives to this patch:
>>
>> 1. The base modes, which are substantially _already_ in place.  They
>>     follow the naming convention <lang>-base-mode.  After giving more
>>     thought to your earlier objection about derived modes overriding
>>     variables, it doesn't make sense (I can elaborate if you want :-) ).
> 
> 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. 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.

It adds an entity called "language" above major modes which are denoted 
with keywords (you could also call it content-types, but that's a longer 
name). The patch implements an implicit language detection as well 
(based on the mode name), but ideally modes that belong to specific 
languages would not have direct entries in auto-mode-alist, etc, at all.

Benefits:
- Avoiding duplicating a bunch of regexps, for ts modes in particular.
- Uncovered an existing bug: ruby-ts-mode didn't add an entry for 
interpreter-mode-alist, only for auto-mode-alist.
- The user could avoid thinking in terms of major modes, and when they 
wanted to enable a fitting mode, they can type 'M-x set-buffer-language' 
and choose one of the known languages with completion.
- Features like Eglot could now call (buffer-language) and dispatch 
based on that (that can make the value of eglot-server-programs more 
compact in the long run).
- Hook <lang>-language-hook is run inside set-auto-mode-0, for the user 
to add customizations to major modes that share the language but no 
common ancestor.

Further possible additions (mentioned previously):
- Potential UI for customizing major-mode-remap-alist to decide which 
major mode to use for a given language, becomes easier/doable.
- Even when there is no installed major mode for a given language, but 
an auto-mode-alist entry for it exists, we could now do something with 
it in fundamental-mode. Like still use Eglot's features, or suggest the 
user installs one of the language support packages for that language 
from ELPA (knowing the language name, we can suggest a specific package).

[buffer-language.diff (text/x-patch, attachment)]

Previous Next

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