Re: eglot-tests fail for emacs-31 branch

On Thu, Jul 23, 2026, 14:21 Michael Albinus <[email protected]> wrote:

>
.  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.
>

Because there is no such information anywhere in the planet or need for it.
It's probably not even a question of versions at all. Eglot works with any
server that speaks LSP.

Again, what happened is just that that naive (but perfectly reasonable)
'npm install typescript-language-server' ceased to work. It would seem now
that something else must be added there to make it work, possibly some
other package or configuration thingy. What? Damned if I know... or care.
Just pin the version like I told you and move on.

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

I've already told you. ANY functioning version will do. Much like any
coffee machine will pour some semblance of coffee if you put water and
beans and plug it in to some source of power.

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.


No! it's absolutely not my job to teach users about configuring pieces of
software other than Emacs how to configure them so they work. That would be
the same as Emacs telling you how to setup your printer or drag a window or
adjust your monitor. Emacs usage rather implies "get a functioning printer,
Emacs will print to it".  The Eglot manual is clear about where this line
is drawn from day 1:

"The language server program must be installed separately, and is not
further discussed in this manual; refer to the documentation of the
particular server(s) you want to install."

Now, as Eglot maintainer I don't give a @$,#+ about this particular server
or have a strong inclination to go debug this basic failure on its part. As
a JS programmer I possibly would give a 4&_+$#, but fortunately I'm not
over anymore.

So I got lucky and found out how to install a functioning typescript
-language-server for EMBA: just pin the version. You've even verified it
works!!! Now, there are probably many many better ways for real JS
programmers who want to actually use Eglot. Possibly, indeed likely, these
users wouldn't settle for old versions, or even use npm, maybe the real
leet JS bros don't even use this server. But it's perfectly up to the job
of helping run Eglot tests to check if it can be connected in a JS buffer
and do some basic things. It'll work for now and for the foreseeable future.

> 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.
>

This is not a problem of any other user other than EMBA (or you rather).
EMBA
, like any other Eglot user, must configure the servers separately. And
that job was easy until now, when JS land messed up. So Michael, as EMBA
caretaker, just pin the version and move on. Trust me on this.

> 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.
>

No, there are hundreds of language servers and many are broken at one point
or another. Debugging this npm "bleeding edge" problem for this particular
server is completely pointless for Emacs and Eglot in particular. Might
make sense for JS programmers to worry about that, or maybe they've agreed
that's how it should work from now on...

> 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.


Tramp and Eglot are completely different programs. So I can understand why
you have that particular biased view of things, and you've likely lost much
hair debugging ssh and fish and sudo problems. Kudos for that, TRAMP is a
superhero program. Now, have you ever used Eglot at all? LSP is a
completely different approach to system interoperation than remote shells
and such. There are indeed "fat" Emacs LSP clients that do the installation
of some servers and hide some of that mess from you. Those would possibly
be more worried about this npm failure (or not, they probably get the
server from somewhere else...).Anyway Eglot is NOT that system.

Also just to clarify this other doubt may have, the test signal I'm
interested in is not "are the all the LSP features of this  particular JS
server working fine with Eglot".  I'm just looking for "does Eglot for
JavaScript work with some server in and basic capacity?".

Anyway, I think that's it!

João

PS: Trust me Michael, pin the versions :)