Re: Making `eglot-server-programs' a custom variable?

[Tim Cross]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Tim Cross <theophilusx@gmail.com>
>> Cc: emacs-devel@gnu.org
>> Date: Thu, 10 Nov 2022 20:34:49 +1100
>> 
>> >> I'm not sure that intent will hold. It has the underlying assumption
>> >> there is a definitive language server for each language.
>> >
>> > No, it doesn't.  Please see the current value of the variable and its
>> > documentation in the manual.
>> 
>> I guess you will have to explain as I've looked at the documentation
>> again and still don't see how you can have two different language
>> servers for the same language. While you can have multiple entries for
>> the same language modes, only the first one in the list take effect.
>
> That's not my understanding.
>
>> >> There are multiple servers for many languages and individual
>> >> preferences/requirements can differ.
>> >
>> > Yes, and the variable already supports that.
>> >
>> 
>> How?
>
> Via eglot-alternatives.  There are entries in the value which already
> use that.  And the change you suggested used that as well.  So I
> wonder what kind of misunderstanding are we having here.
>

That function is not mentioned or referenced in the documentation for
eglot-server-programs. I did see that function when I was configuring
eglot, but it wasn't at all clear to me how it fitted into the
picture. I cold not find any reference to eglot-alternatives in the
eglot manual and it isn't listed in the index, so after you mentioning
it, while I *think* I understand what it does, I still don't see how it
is relevant in this situation (unless you use it in conjunction with
other elisp to implement a new command for selecting which server to
use?).

Not sure how you feel it was part of the change I suggested given I've
not suggested any change - all I did was copy and paste the
configuration I had to add in order to get eglot to work with my
preferred language server for javascript. I really added it to show that
adding a new/different server isn't always straight-forward and that it
requires editing that eglot-server-programs variable. 

>> Please show as it isn't clear to me from the documentation and
>> there isn't a single entry which shows support for multiple language
>> servers for the same language (where only one is active at a time of 
>> course). .
>
> You mean, there's a difference between several servers for the same
> mode and several servers for the same language?  What is the
> difference?  Or is that also part of the misunderstanding?

I don't think 'mode' adds much here. It is really just an emacs specific
notion which langauge servers know nothing about and used to identify
the source language. For example, we have
js-mode and typescript-mode, both modes for editing/developing
javascript. However, there is more than one language server mode for
javascript. The 'default' is typescript-language-server, my preference
is deno. Both are language servers for javascript and typescript. 

Different language servers for the same language can offer different
features or different strategies in supporting a feature. One server
might have different snippets, different lint rules, different
formatting rules or use a different strategy for implementing things
like code completion or simply have a different performance profile.

As it stands now, you have an alist with keys that are emacs mode names
and values which are the language server to run (along with command line
arguments etc) when you use eglot in one of the modes used as the key.

I cannot see how you can have two separate entries for (js-mode
typescript-mode) or if you do, how the user indicates which entry to
use.

In my case, my configuration of deno works because it appears in the
list before the default entry which uses
typescript-language-server. Your suggestion was that if there is a
server not in the list, it should just be added to the list. I still
don't see how this would work in the general case. If there are two
entries in the list with the same key, how does the user identify which
entry they want to be used?

It was this which made be suggest that your suggestion that this
variable would typically not need to be modified by end users may not
hold. I think it will be something which users will often need to do -
especially as this space is still evolving and the status of servers for
many languages are still somewhat in flux.

Note that I may not agree 100% with the OPs position that the manual
should be updated. When adding code to your init.el file, cut and paste
examples frequently get people into more trouble than help. I think that
if your going to add calls to add-to-list in your init.el file, you
relaly should understand what that means and why you cannot add to a
list which doesn't yet exist etc. However, I disagree with the
suggestion this variable is some internal variable which won't need to
be modified by users.

I also wanted to highlight that in this specific case of adding deno as
a server, it was much easier and more straight-forward to do so with
lsp-mode than it was in eglot. This is not a suggestion that lsp-mode is
better - for many reasons, I very much prefer the architecture and
design goals of eglot over lsp-mode. It was mentioned as just a data
point from someone who has used both. Note also that I did initially try
adding deno useing the simple/naive approach as outlined in the manual,
but could not get that to work. In the end, I got it working after some
help from IRC.