bug#62694: 30.0.50; eglot-tests fails with recent pylsp

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

Michael Albinus <michael.albinus@gmx.de> writes:

> João Távora <joaotavora@gmail.com> writes:
>
> Hi João,
>
>>> That earlier proposals were not complete, optimal, or up to yours or
>>> anyone's standards does not warrant degrading them, IMO.  
>>
>> - vague: there are no details, just the idea of "checking if the server
>>   is up to the job".
>
> I've shown you the Eglot traces for one test case on both Debian pylsp
> (failed) and Fedora pylsp (succeeded). I still have no idea whether the
> Debian flavour is inside the LSP specs or not. But if it returns
> out-of-spec replies, I guess eglot should raise an Emacs error
> indicating this fact.

It's _not_ an out-of-spec reply.  It's just a insuficient in-spec reply
from a poorly installed or configured server.  The point of these tests,
as I've explained multiple times, is not to test the servers, rather
eglot.el's particularly its interactions with other emacs facilities,
such as xref, completion, flymake etc.  Any server will do, as long as
it is reasonably well-behaved and predictable.  That's why I switched to
clangd and all this discussion is moot now.

> Based on this fact, you could always catch this specific error in the
> tests, and say that the server is not suited. Whether you shall skip
> or err out the test then is something else; until now it isn't obvious
> that a failed eglot test is due to the (possible) server misbehavior,
> or due to an eglot error. At least this information should be shown.

It's impossible to know that.  You can design perfectly in-spec naughty
servers breaking all of eglot tests. Or you can follow Eglot's
maintainer advice to install versions of servers known to be working
correctly.  Heroically complexifying Eglot to detect misbehaving servers
is a completely futile exercise.

João