Externalising 'eglot-server-programs'

Externalising 'eglot-server-programs'

[Philip Kaludercic]

I have been wondering why all the language servers are currently listed
in 'eglot-server-programs'?  Isn't it usually the responsibility of a
major mode to integrate and configure generic functionality (Imenu,
CAPF, Xref, Outline, Font-Lock, ...) for a language?  Would it be
imaginable to move towards the expectation that major modes and their
packages update 'eglot-server-programs', just like they update
'auto-mode-alist'?

-- 
	Philip Kaludercic on peregrine

Re: Externalising 'eglot-server-programs'

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Date: Wed, 17 Jul 2024 22:23:12 +0000
> 
> 
> I have been wondering why all the language servers are currently listed
> in 'eglot-server-programs'?  Isn't it usually the responsibility of a
> major mode to integrate and configure generic functionality (Imenu,
> CAPF, Xref, Outline, Font-Lock, ...) for a language?  Would it be
> imaginable to move towards the expectation that major modes and their
> packages update 'eglot-server-programs', just like they update
> 'auto-mode-alist'?

We should keep in mind that Eglot is also available from ELPA, so it
cannot necessarily rely on what major modes in core do, because
3rd-party major modes might not do that.

Also, I don't see what possible harm could be caused by having all the
known servers listed in that variable.

Adding João to the discussion.

Re: Externalising 'eglot-server-programs'

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 553 bytes --]

On Thu, Jul 18, 2024, 06:04 Eli Zaretskii <eliz@gnu.org> wrote:

> Adding João to the discussion.

eglot-server-program singular (or eglot-contact) has long been in the
roadmap. The e-s-programs is from Eglot's out-of-tree days.

If someone wants to work on this, show a patch, for code and doc that keeps
100% backward compatibility to the e-s-programs variable, which should
probably not be deprecated.

New variable should allow expressing everything the plural variable does,
including multi-language servers (see bug#72088).

João

[-- Attachment #2: Type: text/html, Size: 691 bytes --]

Re: Externalising 'eglot-server-programs'

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Philip Kaludercic <philipk@posteo.net>
>> Date: Wed, 17 Jul 2024 22:23:12 +0000
>> 
>> 
>> I have been wondering why all the language servers are currently listed
>> in 'eglot-server-programs'?  Isn't it usually the responsibility of a
>> major mode to integrate and configure generic functionality (Imenu,
>> CAPF, Xref, Outline, Font-Lock, ...) for a language?  Would it be
>> imaginable to move towards the expectation that major modes and their
>> packages update 'eglot-server-programs', just like they update
>> 'auto-mode-alist'?
>
> We should keep in mind that Eglot is also available from ELPA, so it
> cannot necessarily rely on what major modes in core do, because
> 3rd-party major modes might not do that.
>
> Also, I don't see what possible harm could be caused by having all the
> known servers listed in that variable.

It is not so much harm, but just that it is easier for a the maintainers
of a major mode to evaluate and perhaps change anything related to the
LSP server configuration, than if they have to make the change in some
other project (in this case emacs.git).  I'd also guess that people
maintaining a specific major mode have more experience and are better at
testing edge-cases specific to a language{,server} than the average
Emacs developer.

> Adding João to the discussion.
>
>

-- 
	Philip Kaludercic on peregrine