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

Previous Next

Full log

Message #379 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: Thu, 18 Jan 2024 02:47:16 +0200

On 17/01/2024 12:20, João Távora wrote:
> On Wed, Jan 17, 2024 at 2:41 AM Dmitry Gutov <dmitry <at> gutov.dev> wrote:
> 
>> An "abstract" mode is supposedly one that doesn't do anything. So it
>> doesn't have to be callable.
> 
> No.  Not "abstract" as in "Java interface", abstract as in "Java
> abstract class".
> 
>> Anyway, that's +1 feature required for the implementation.
> 
> Almost trivial feature.  See patch after sig.  It'll make this work:
> 
> (define-derived-mode foo-mode prog-mode "Fooey" :abstract t
>     (message "Hey from foo-mode"))
> (define-derived-mode bar-mode foo-mode "Barey"
>     (message "Hey from bar-mode"))
> 
> 'foo-mode' can't be called, but 'bar-mode can, of course.  And it
> will call its parent.

What would such an "abstract" parent do anyway? Still set up keymaps etc?

>>> 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.
> 
> Sure?  I see a super-normal css-base-mode inheriting from
> prog-mode.
> 
>> TeX modes also do not derive
>> from prog-mode. TeX does have an LSP server, however.
> 
> At the end of the day we have to come to a conclusion of what
> we want to do.  I want to find major modes that correspond
> to languages, right?  So:

Right. But I suppose it's more or less the set of modes that correspond 
to file types (files on disk). Even text-mode, often used as a fallback, 
could have a language ("plain text") - you can see this file type (or 
"language mode") in the dropdown list of choices in editors that support 
switching between them with a mouse (e.g. VS Code).

> * these outliers start inheriting from prog-mode
> * we inject new lang-mode between prog-mode and fundamental-mode and make
>    outliers derive from that.
> * we say these outliers aren't languages
> * we code exceptions for these outliers
> 
> It could even be that
> 
> (derived-mode-add-parents 'tex-mode '(prog-mode))
> 
> is exactly what's needed here, showcasing how I think this
> particular heavy hammer should be used for the exception, not
> the rule.

Also, arguably, Makefile-mode should not be a prog-mode derivative 
because its indent-line-function is not meaningful. But we want to 
support it with LSP anyway (I think), and with other features that 
dispatch based on the current language.

>>>> 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.
> 
> Perfect.  But the, "set-buffer-language" comment?  Does a buffer object
> have to exist for that job to be done?

No, you could just do something like

  (defun get-current-mode-for-language (lang)
    (with-temp-buffer
      (set-buffer-language lang)
      major-mode))

Previous Next

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