Re: eglot-tests fail for emacs-31 branch

João Távora <[email protected]> writes:

> Hi again, Michael

Hi João,

>> So yes, these versions of typescript-language-server and
>> vscode-json-languageserver should be supported. Emacs 31 users will
>> see them.
>
> Here's the thing: probably many other version -- even the most recent
> versions that broke EMA -- are supported as long as you configure them
> correctly.  It's just EMBA is not doing that (and shouldn't have to
> worry about that, IMO).

What do you mean with "configure ... correctly"? There is absolute no
information about which versions of typescript-language-server and
vscode-json-languageserver must be used.

Emba tests, whether Emacs runs for an ordinary user. Such a user takes
Debin trixie, for example. She dos not know which language servers to
install, so she uses the available ones. Be it via npm or snap, it
foesn't matter.

If we give some guidamce in Emacs which versions have be tested, she
will do. And Emba will follow this doc.

>>> In practice, and concretely to the Eglot failure in question, I am more
>>> than happy if the signal is: "does Eglot currently work with _some known
>>> good version_ of typescript-language-server"?  That's because Eglot can
>>> be combined with so many other things, that I know with almost 100%
>>> certainty that, out there, there is some combination of language server
>>> + OS + myriad other thing that makes Eglot fail.
>>
>> Sure, we can pin versions to be tested on emba. But that's a moving
>> target.
>
> Is it?  Isn't it the opposite.  I think the pinning I suggested will
> work for a good long while, if not "forever".

It is a suggestion you have made for elpa. Document it in Emacs, that
users in  the wild (who don't know emba) can apply, and emba will follow.

>> I would appreciate if we could have this documented, at
>> least. Something like a comment in eglot.el, "tested with xxx language
>> server 123". And then we need to establish a policy, how these
>> versions can be changed over the time.
>
> I think that's too complex and brings little value.  There are hundreds
> of language servers in various variations and versions . I appreciate
> that Eglot is tested routinely on EMBA with a fair number of servers
> including this now-slightly-older version of typescript-language-server.
> But that's not the only place I run test Eglot (in fact it's not my
> primary place).  For example, in my laptop I have 5.3.0 but it somehow
> is functional, and if it ever becomes non-functional with that bizarre
> error I can probably fix it here.  In my other laptop I have probably an
> even older version.  The point is that Eglot should be testable with
> whatever _functional_ version of typescript-language-server one has
> lying around.  It shouldn't require a specific version in
> eglot-tests.el, that is fragile.
>
> Bottom line is that if EMBA wants to help in test Eglot in this
> particular regard, then all it has to do is have a functional version of
> this server lying around.  The npm version pinning I suggested is _a_
> way to do that, perhaps the simplest way, and you've confirmed it works.
> But if you prefer finding the server in apt or snap or the newest JS
> package manager du jour I have no objections of course.

Again, emba will follow any recommendation which is documented. Just
pinning a version because you told me so is of no help for users in the wild.

>>> If they pass there's a good change that it's a good change to commit
>>> to the Dockerfile.
>>
>> I will do once we have agreed how to handle this version pinning in general.
>
> OK.
>
>> Now that we know it isn't a showstopper for Emacs 31.1, I can live with
>> this error for a while. And it would be great if you could find a
>> solution in eglot.el, or at least a condition for skipping the two tests
>> in eglot-tests.el.
>
> I hope I've explained above why that is counter-productive: such a
> condition would be complex to setup, fragile and needlessly cripple the
> tests for other functional non-EMBA typescript-language-server
> installations.

??? Simple find out why this configuration doesn't work. I'm convinced
it is a (sub-)feature of a language server which behves different
now. If we know what it is, and we handle it in eglot and/or
eglot-tests. everybody would profit from. Not only emba tests.

>> Emacs users will report about this error in the
>> future (I'm sure),
>
> They might, but I wouldn't be surprised if they don't.  The LSP server
> landscape is vast and fragile and people sort of expect this breakage.
> Especially the JS folks, this is probably old news to them, they probaly
> use a project-specific server, not a rolling global installation (much
> like the Python folks likely do with virtual envs).
>
>> and we should be happy that we can reproduc the error
>> locally. So we have a chance to fix.
>
> I really wouldn't be happy :-), just indifferent.  There would be
> nothing to fix, and nothing interesting to learn.  This particular
> problem ("the server is here but typescript not found") is a failure by
> the user and typescript-language-server (chiefly the latter, probably)
> to set things up correctly.  That's completely outside the realm of
> Eglot, so my answer would be say sorry and close the bug.

I believe it is too simple. We are responsible to help users fixing
their problems. With such an approach, Tramp (I'm responsible for) would
be dead sfor decades.

Yes, we diagree in our philisophy.

> João

Best regards, Michael.