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

Previous Next

Full log

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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: João Távora <joaotavora <at> gmail.com>
Cc: 68246 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, casouri <at> gmail.com,
 Stefan Kangas <stefankangas <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: Wed, 17 Jan 2024 04:41:00 +0200

On 16/01/2024 13:06, João Távora wrote:

> Agree.  And this is why I'm not crazy about the solution either.  But as
> to cluttering the function namespace we could say that (:abstract t) modes
> do _not_ generate a function (or do not generate them in the public
> namespace -- as I think the function still has to exist for any
> concrete submodes down the line to call it).

An "abstract" mode is supposedly one that doesn't do anything. So it 
doesn't have to be callable.

Anyway, that's +1 feature required for the implementation.

>>>> This choice is coupled with the corresponding logic in 'buffer-language'
>>>> (whether to keep the replace-regexp-in-string branch).
>>>
>>> Yes.  I think we should err on the side on convenience.  What exactly are
>>> the defects can we get?  I can't see anything else but the tuareg-mode, and we
>>> can plug that on our side.  Maybe you can see more.
>>
>> For example, it would sometimes return ugly non-existent languages like
>> :help-fns--edit-value, :org-lint--report or :xref--xref-buffer.
> 
> What if we filter by prog-mode?  It would leave the ':ruby-base' and
> ':python-base' as false positives, I guess.  But then we could reasonably
> say that anything ending with '-base' is abstract (or use the
> aforementioned  explicit abstract prop).

We would also filter out :css, for example. TeX modes also do not derive 
from prog-mode. TeX does have an LSP server, however.

> It would also make ':lisp-data' a language.  But that's not bad.
> lisp-data-mode is actually a useful concrete prog-mode derivative,
> so I think it's OK to have ':lisp-data' as a language.
> 
> We can then have exceptions for some notable cases.  'lisp-mode' is
> as we know, for Common Lisp only.

>>>> Are there specific uses for get-mode-for-language when there is no
>>>> existing buffer?
>>>
>>> Yes, I'd say this markdown-mode use is exactly that.  Markdown inserts
>>> some text into a buffer and all it knows is the language it's supposed
>>> to fontify it with.  The major mode has that logic, so it must invoke
>>> the correct (and preferred) major-mode function.
>>
>> Sorry, I meant get-language-for-mode (which is the one implemented as
>> buffer-language currently).
>>
>>> Another use is allowing the user to choose major modes for languages,
>>> say from a tutorial or wizard or at Emacs startup.  Say, I prefer
>>> ruby-ts-mode for Ruby, but c++-mode for C++.  It'd be helpful to summarize
>>> those preferences.
>>
>> This would require capabilities like "get all modes for a language" (not
>> one of the set of functions mentioned so far, and it'll need a full scan
>> of major-mode-remap-alist) and "get current mode for a language" (this
>> one matches markdown-mode's function you posted).
> 
> Yes.  I don't see the full scan of m-m-remap-alist as problematic
> from a effiency perspective.  If we decide it's the database, it's
> the database.   It's unfortunate that the "alist" implementation is
> hardcoded in the name (which is why I would prefer a (:language "Foo")
> kwarg to define-derived-mode) but we can abstract the alist aspect
> away with accessors and do the usual "Do not change this variable
> directly, use these accessors instead".

I'm not saying in advance that it will be slow. Just that it's a 
different function.

>> BTW, get-current-mode-for-language could be implemented in terms of
>> set-buffer-language.
> 
> What does get-current-mode-for-language do exactly?

The major-mode currently configured to be used for the language (through 
m-m-a-alist, in the current proposal). set-auto-mode will choose it.

>>>> We could have both functions: buffer-language and get-language-for-mode
>>>> ('get-mode-language'?). Or define one initially and add the other as needed.
>>>
>>> Yes.  buffer-language isn't bad, it's a useful helper.  But buffer-language
>>> should be just
>>>
>>>      (with-current-buffer buffer (get-language-for-mode major-mode))
>>>
>>> Right?  Modulo some caching if it turns out to be very inneficient
>>> (which I really doubt)
>>
>> Again: this won't work for files where no suitable major mode is
>> available (e.g. not installed yet).
> 
> Right. So maybe
> 
> (or (with-current-buffer buffer (get-language-for-mode major-mode))
>      (let (kw)
>         (and buffer-file-name
>              (keywordp (setq kw (alist-get buffer-file-name auto-mode-alist)))
>              kw))
>      (consult-oracles)
>      (error "Don't know what language this is, sorry"))

Replied to this one in another email: referring to the results of the 
computation of set-auto-mode is easier. But that's a technical detail.

Previous Next

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