emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Explain a bit more on how to configure language server in Eglot's ma


From: João Távora
Subject: Re: Explain a bit more on how to configure language server in Eglot's manual
Date: Wed, 8 Mar 2023 13:54:55 +0000

On Wed, Mar 8, 2023 at 1:27 PM Augusto Stoffel <arstoffel@gmail.com> wrote:

> So if the difficulty of gathering these data is overcome, Eglot could do
> something actually helpful and show a listing with the types and
> documentation of the options (whatever the specifics look like).

If and when the LSP protocol stops specifying options as an "LSPAny"
object and builds some protocol on top of it to communicate schema
Eglot will evaluate if there's some tangible benefit of
getting that from the server.  Until then, anything you do
with this information is language-server specific.  It should
go into a major-mode or a different extension...

> > The dotted-to-plist translator proposed is optional.  Some people
> > requested use of dotted notation and that will surely need a
> > translator.  I wouldn't use it.
>
> Given how selective you are with the features you want to add, I don't
> understand why you think this particular one should make it in.  It
> would sure help a little, maybe, sometimes.

I don't understand: didn't you state you _like_ dotted notation?
Well, this translator is needed for it, because the e-w-configuration
variable is a plist.  I reject features which I consider bloat, i.e. they
have no bearing to LSP in particular or they solve too specific
a problem that should really be solved somewhere else (normally this
isn't done simply because that takes more effort and discussion).
A special plist editing mode for a single Eglot variable falls into
that category, IMNSHO.

Dotted option notation does not.  It seems to be an LSP practice,
and I don't see any other good place to put a single utility function
that facilitates it but in Eglot.  If it helps people "a little"
and has close to 0 maintenance cost, then I don't see why it shouldn't
be included.

And yes, there are already examples of bloat in eglot.el. But two
wrongs don't make a right.  There was some bloat that I've already
extracted and put in its rightful place, like the "external" completion
style.  And there was jsonrpc.el in the beginning.  Another example
is Eglot's "glob compiler" needed for LSP but probably more generally
useful and which also belongs elsewhere.  Currently I'm also looking
to move the markdown rendering to eldoc.el: Eglot shouldn't be doing
that.  If you're looking to contribute, I'm much more open to patches
that reduce_ Eglot's bloat than ones which potentially increase it.

João



reply via email to

[Prev in Thread] Current Thread [Next in Thread]