Re: [GNU ELPA] eglot-x.el: Protocol extensions for Eglot

["João Távora" <joaotavora@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> João intend to support only the standardized protocol features in
>> eglot.el, but lots of LSP servers extend the protocol in their own way.
>> (It was João who suggested the package name long ago.)  I considered
>> eglot-x just an experiment and a learning possibility, but people seem
>> to use it, so I'd like to make their life easier by this submission.
>
> It sounds strange to me to refuse to support LSP extensions in
> eglot.el.

Noone "refused" anything.  Some years ago, Felicián and I came to this
agreement.  If there is an actual patch for eglot.el being proposed, I
can review it.  Felicián has contributed much code for eglot.el and they
are very appreciated.

> At the very least, eglot.el could benefit from offering a
> supported mechanism for adding such extensions; there should be no
> need for using advice for that.

I agree.  Eglot has an API.  I haven't looked at eglot-x in depth but I
suspect it's using some of this API in part.  If it's not sufficient,
then Eglot could enhance it.  What part of eglot-x is using advice, if
any?

> João, why would you not consider supporting these extensions as part
> of eglot.el?

They're non-standard, each server has its own set of extensions, which
in some cases could be volatile and become obsolete.  Furthermore, I
would suspect that if eglot-x.el modifies eglot.el's standard behaviour,
it is not as well tested across different servers and could provide a
surprise for users of other servers.

A guiding principle of eglot.el (and indede LSP) is to not have any
server-specific code.

The only such (reasonably manageable) exception is the
eglot-server-programs variable.  But even this variable should ideally be
dissipated across settings in major modes, as was frequently suggested
for gdscript.el mode with much success.  I plan to spin it off to a new
file in the near future, as it is growing very fast.

Furthermore, I presume some of these extensions need some kind of
user-facing UI, and Eglot is conservative about that.  As frequently
explained, I generally prefer using non-LSP generic UIs that integrate
well with all parts of Emacs.  Fine tuning the design of such UIs takes
time and care.

So in general, I think having eglot-x.el as a kind of laboratory where
authors can experiment freely with new LSP-powered UIs is an excellent
approach.  As these extensions make their way into the official LSP
protocol Eglot can support them.  For example, I believe "inlay hints"
started as some kind of rust-specific protocol extension and is now
well-supported in Eglot for many servers (I use it daily).

We could consider bundling eglot-x.el with the Eglot ELPA package (I do
hope Felicián is aware of the ins and outs of :core packages though).
And I think a separate package isn't really bad either.

João