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

Previous Next

Full log

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

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

On 10/01/2024 08:24, Stefan Kangas wrote:
>> Also, "what language is this" does happen to be a meaningful question.
>> Eglot's example aside, we can have other tools, databases, etc.
> I can't speak for Stefan M but AFAIU he agrees that "which language
> corresponds to this mode" is something we want to answer.  He just
> proposes using the taxonomy we already have for this, instead of adding
> a new one.
> 
> I.e. the difference is:
> 
>      (derived-mode-p 'foo-mode)   vs    (language-for-mode-p 'foo)
>      Monnier                            Távora
> 
> Either of those would answer the question "does the current buffer
> contain language FOO".  The former reuses the old taxonomy, the right
> introduces a new one.

The predicate is available, but implementing the function that decides 
on the current buffer's language is harder.

Because js-mode derives from prog-mode as well. You can't really take 
the current major mode, or an ancestor, slash away "[ts-]-mode", and say 
"this is the name of the language", because it's hard to decide which of 
them to use.

>> Finally, if we did have "languages" as an entity, we could have some UI
>> for the user to choose the mode for a language - something like Debian's
>> 'update-alternatives'. And it would also serve to list the supported
>> languages, I guess.
> This is a good point.  Also to install extensions for those languages.
> Or we could use it to implement the VSCode-like prompt "hey this seems
> to be language <foo>, do you want to install support for it?".

Yup.

Or - as long as the language name is decidable, allow the user to just 
enable, say, fundamental-mode, call 'M-x eglot' and have it provide both 
syntax highlighting and indentation support through LSP. This might not 
always be practical (and syntax highlighting is not implemented in Eglot 
yet), but it seems like an interesting possibility. Especially in those 
rare and purely hypothetical cases when an LSP server for a language 
exists, but there is no Emacs major mode yet.

Previous Next

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