microsoft
LSP diagnostics not working in Emacs's eglot
TL;DR: tsgo does not send textDocument/publishDiagnostics to eglot (Emacs LSP implementation).
For comparision, typescript-language-server does send it.
Maybe there's a slight difference in the client capabilities which tsgo expects? Looking at the code I can't identify whether tsgo has some specific expectation for a client capability.
Here's a transcript of the communication eglot <-> LSP server, for both tsgo and `typescript-language-server``: https://gist.github.com/edkolev/c23f5cf03dc66f1efa2de855b5f7d2aa
The transcript is obtained by just opening a .ts file.
IIUC the transcript, tsgo doesn't send textDocument/publishDiagnostics. There seems to be no difference in how eglot presents itself to either server.
Related discussion in eglot's project: https://github.com/joaotavora/eglot/discussions/1559
We only support pull diagnostics (textDocument/diagnostic, https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_pullDiagnostics). Push diagnostics are currently only used for config file errors.
Does eglot not support this?
(It's a significant architectural change to use push diagnostics, which we haven't looked into yet.)
Hello @jakebailey. Eglot now supports "pull diagnostics", however I found tsgo --lsp --stdio doesn't do a very useful thing that other servers, like C++'s clangd do with textDocument/publishDiagnostics which is to provide diagnostics for documents directly affected by a change to one document. As far as I can read in the LSP spec, there is the 'relatedDocumentSupport' client sub-capability, but no server that I know consults it or does anything useful with it.
Like tsserver before it, the new language server only shows diagnostics in opened files.
#2169 covers diags for unopened files.
In my tests, I have two opened documents, main.ts and lib.ts. I naively expected the language server to maintain a dependency graph and a diagnostic pull to lib.ts after a document change to bring in diagnostics for main.ts too. Someone told me VSCode requests diagnostics for all opened files but not only do I care chiefly around the spec rather than other clients, I think that's inefficient. But OK. Glad I fled JS land myself a long time ago.