bug#61679: 29.0.60; Eglot: staying out of trouble

bug#61679: 29.0.60; Eglot: staying out of trouble

[Augusto Stoffel]

Eglot modifies several Emacs features, and it seems to do so
independently of the server capabilities.  For instance, it registers a
capf and Eldoc functions even if the server does't provide completions
respectively "hover"/signature help.

In some cases (capf, xref) this seems innocuous, in others (eldoc) Eglot
is really overwriting a possibly useful function with a possibly useless
one.

Now, the above are somewhat silly examples, but the Flymake case is
quite problematic.  There exist good servers that don't provide
diagnostics, and Eglot still overwrites `flymake-diagnostic-functions'.
To make things worse, LSP doesn't provide a way to the server to advertise
whether or not it provides diagnostics.

I would suggest that Elgot initially should keep
flymake-diagnostic-functions unchanged, and only overwrite it when the
first diagnostic comes from the server.

bug#61679: 29.0.60; Eglot: staying out of trouble

[João Távora]

On Tue, Feb 21, 2023 at 2:32 PM Augusto Stoffel <arstoffel@gmail.com> wrote:
>
> Eglot modifies several Emacs features, and it seems to do so
> independently of the server capabilities.  For instance, it registers a
> capf and Eldoc functions even if the server does't provide completions
> respectively "hover"/signature help.
>
> In some cases (capf, xref) this seems innocuous, in others (eldoc) Eglot
> is really overwriting a possibly useful function with a possibly useless
> one.

In the Eldoc case, as of yesterday, this no longer happens.

Look at

commit e83c78b8c7784254c2c6f043530ab325c2fa7f16
Author: João Távora <joaotavora@gmail.com>
Date:   Mon Feb 20 22:43:50 2023 +0000

    Eglot: respect user's Eldoc configuration by default

> I would suggest that Elgot initially should keep
> flymake-diagnostic-functions unchanged, and only overwrite it when the
> first diagnostic comes from the server.

This seems way too complicated for a problem that hasn't even been
demonstrated.  The reason there's no capability announcement for
diagnostics is likely because it's such a basic capability that
virtually every server supports it, unless you go out of your way
to find or craft one that doesn't.

When activating Eglot, you're saying "let this here LSP server
manage my buffer by connecting it with these Emacs infrastructures"
You're letting go of some of your major-mode's configuration
and user configuration for what is in 99% of the cases a much more
integrated and hassle-free IDE experience.

Even so, Eglot only temporarily overrides your configuration and
will not do so gratuitously, as the commit above illustrates.  In
Flymake's case, it is really important to override the value by
default or else super-popular languages like Python handled by
python mode start showing confusing duplicate diagnostics to
newbie users, and we don't want that.

If you really like your pre-Eglot configuration, you can combine
it with Eglot's by leveraging eglot-managed-mode-hook and
eglot-stay-out-of. This was Eglot's philosophy from the start and
I don't intend to change it.

João

bug#61679: 29.0.60; Eglot: staying out of trouble

[Augusto Stoffel]

On Tue, 21 Feb 2023 at 15:00, João Távora wrote:

> In the Eldoc case, as of yesterday, this no longer happens.

Okay, nice.

> This seems way too complicated for a problem that hasn't even been
> demonstrated.

jedi-language-server doesn't provide diagnostics and it's officially
supported and rather popular.  (My digestif server also doesn't support
it but I'm not going to mention that.)  Since I only ever used 3
servers, I think the situation is not that rare.

> The reason there's no capability announcement for diagnostics is
> likely because it's such a basic capability that virtually every
> server supports it, unless you go out of your way to find or craft one
> that doesn't.

I think you are being too kind with the designers of the protocol :-).

bug#61679: 29.0.60; Eglot: staying out of trouble

[João Távora]

On Tue, Feb 21, 2023 at 3:09 PM Augusto Stoffel <arstoffel@gmail.com> wrote:
>
> On Tue, 21 Feb 2023 at 15:00, João Távora wrote:
>
> > In the Eldoc case, as of yesterday, this no longer happens.
>
> Okay, nice.
>
> > This seems way too complicated for a problem that hasn't even been
> > demonstrated.
>
> jedi-language-server doesn't provide diagnostics and it's officially
> supported and rather popular.

I just read in https://github.com/pappasam/jedi-language-server that it
supports textDocument/publishDiagnostics.

If that's a mistake, then I guess it's meant to be used in conjunction
with other language servers at the same time which complement its
features.  Eglot doesn't support that, but I'm working on a solution,
even though it will take time.

> My digestif server also doesn't support it but I'm not going to
> mention that.

Right :-) I'm also not going to mention that if there is some way at
all to get diagnostics for Latex, then you could think of including
that way into digestif.  Many servers do that: they are just LSP
aggregators of existing diagnostics/completions/etc tools.

Just suggesting because it's one way to go.  The other is for users
to use eglot-stay-out-of, etc...

João

bug#61679: 29.0.60; Eglot: staying out of trouble

[Augusto Stoffel]

On Tue, 21 Feb 2023 at 15:17, João Távora wrote:

> On Tue, Feb 21, 2023 at 3:09 PM Augusto Stoffel <arstoffel@gmail.com> wrote:
>>
>> On Tue, 21 Feb 2023 at 15:00, João Távora wrote:
>>
>> > In the Eldoc case, as of yesterday, this no longer happens.
>>
>> Okay, nice.
>>
>> > This seems way too complicated for a problem that hasn't even been
>> > demonstrated.
>>
>> jedi-language-server doesn't provide diagnostics and it's officially
>> supported and rather popular.
>
> I just read in https://github.com/pappasam/jedi-language-server that it
> supports textDocument/publishDiagnostics.

Okay, that's a somewhat new feature.  The concept seems to be that it's
better to provide rudimentary diagnostics than nothing at all.  I'm not
sure I like the idea.

In any case, it seems to support your point that servers without
diagnostics will be rare, so feel free to close the bug.

> If that's a mistake, then I guess it's meant to be used in conjunction
> with other language servers at the same time which complement its
> features.  Eglot doesn't support that, but I'm working on a solution,
> even though it will take time.

Oh well, if multiple servers is the new trend, then I guess this might
become necessary...

bug#61679: 29.0.60; Eglot: staying out of trouble

[João Távora]

On Tue, Feb 21, 2023 at 3:32 PM Augusto Stoffel <arstoffel@gmail.com> wrote:

> any case, it seems to support your point that servers without
> diagnostics will be rare, so feel free to close the bug.

OK.

>
> > If that's a mistake, then I guess it's meant to be used in conjunction
> > with other language servers at the same time which complement its
> > features.  Eglot doesn't support that, but I'm working on a solution,
> > even though it will take time.
>
> Oh well, if multiple servers is the new trend, then I guess this might
> become necessary...

I'm not sure it's a new trend, but it has some use cases, yes.
I think it was once more urgent than it is now, where some
servers do the aggregation from multiple sources themselves.

In the Eglot Github page there are a few discussions: the biggest
use case I've seen described is for JavaScript which normally
wants to have EsLint linting and also other types of servers.  But I
think this also makes sense more generally.  A spell-checking server
could go hand-in-hand with multiple programming servers.

João

bug#61679: 29.0.60; Eglot: staying out of trouble

[João Távora]

On Tue, Feb 21, 2023 at 3:53 PM João Távora <joaotavora@gmail.com> wrote:
>
> On Tue, Feb 21, 2023 at 3:32 PM Augusto Stoffel <arstoffel@gmail.com> wrote:
>
> > any case, it seems to support your point that servers without
> > diagnostics will be rare, so feel free to close the bug.
>
> OK.
>
> >
> > > If that's a mistake, then I guess it's meant to be used in conjunction
> > > with other language servers at the same time which complement its
> > > features.  Eglot doesn't support that, but I'm working on a solution,
> > > even though it will take time.
> >
> > Oh well, if multiple servers is the new trend, then I guess this might
> > become necessary...
>
> I'm not sure it's a new trend, but it has some use cases, yes.
> I think it was once more urgent than it is now, where some
> servers do the aggregation from multiple sources themselves.
>
> In the Eglot Github page there are a few discussions: the biggest
> use case I've seen described is for JavaScript which normally
> wants to have EsLint linting and also other types of servers.  But I
> think this also makes sense more generally.  A spell-checking server
> could go hand-in-hand with multiple programming servers.
>
> João



-- 
João Távora