Re: Eglot to core [Was: rmsbolt.el [Was: Colorful line numbers]]

[Felician Nemeth <felician.nemeth@gmail.com>]

>> I don't think the current API is good enough for that.  See
>> https://github.com/joaotavora/eglot/discussions/802#discussioncomment-2171239
>
> Really depends on what you consider "that" to be.

To implement non-standard LSP features, which lots of servers propose.

> [...] Also, once Eglot is in core, I won't be only person deciding.

(I welcome Eglot's inclusion in the core and appreciate your work.  I
hope that's clear.)

>> More importantly, there are multiple language server implementations for
>> some languages (python, c) with different quirks or non-standard
>> extensions to the LSP protocol.  How do you imagine a major-mode would
>> support these?
>
> They can adds methods to the generic function eglot-handle-request (and
> a handful others), set values of Eglot in their major-mode
> initialization code, bind keys to `eglot-*` interactive commands, make
> compound commands from those commands, etc.

OK.  This is somewhat similar to the case when a major mode provides an
xref or a flymake backend.

But I think sometimes the reverse approach is more desirable.  Let's
take a not so hypothetical example and say c++-mode wants to provide a
type-hierarchy browser.  It's better to write a generic, language
agnostic hierarchy browser (maybe CEDET even has one), and extend Eglot
with a hierarchy browser backend similarly to its xref backend.  The
hierarchy browser then can have a tree-sitter backend as well.

> While they _can_, but that doesn't mean they _must_ or even _should_.
> In fact, LSP's whole idea, which is surprisingly forgotten so often, is
> that server and editor need to know very little about each other to be
> able to cooperate.  By and large this idea works very very well. 

I agree, but non-standard extensions exist for a reason.

Almost all servers have a VS-Code specific part that contains at least a
list of configuration variables that other clients cannot handle
automatically.  BTW, if Eglot knew about these configuration variables,
could `customize-group` somehow save the settings into a .dir-locals.el
file?

> Eglot works with tens of servers and hasn't got a line of server
> specific code, except for eglot-server-programs invocations.  There
> are exceptions, and not everyone has the same luck, but I've been
> using C++ clangd and C# omnisharp quite a lot lately and I have 0
> lines of server specific config.

Even clangd has a moderately long list of extensions:
https://clangd.llvm.org/extensions.html#type-hierarchy
Sure, clangd is usable without them, but some of the extensions might
make someone's life easier, for example, by providing a type hierarchy
browser.

> [...] So there isn't any problem/drama here.

I don't want to start one either, but it's a good time to think once
more about Eglot's relations with other packages.