feat(lsp): support textDocument/diagnostic specification

[woojiq]

Closes #7757

Explanation for easier review, see #7900 (comment).

Tested manually with ruby-lsp.

[woojiq]

Few notes for easier review.

I took a large piece of code from PublishDiaagnostic notification and splited in two methods:

• lsp_diagnostic_to_diagnostic
• add_diagnostics

Added text_document_diagnostic method to send actuall json-rpc request, it looks like any other text_document_* method (hover, definition etc). And the actual thing you want to review is pull_diagnostic_for_current_doc which is called later in handle_idle_timeout . There is nothing hard tbh. Just send a server request, then create callback for extracting info from response (aforementioned method lsp_diagnostic_to_diagnostic and add_diagnostics are reused).
And the last thing to mention is I added field supports_publish_diagnostic for Client, during first "PublishDiagnostic` notification from a server set this field to true. And then, if it is true, we do not run PullDiagnostic. I think we should prefere Publish.

[pascalkuthe]

I think it makes sense to delay this until the event system (#8021) lands. We really only want to pull diagnostics of all visible documents (only when the contents of any document actually changed, likely with a debounce, if interFileDependencies is false in the capabilities we actually only need to pull if a visible file has changed). This kind of use case is precisely what I intended the event system for.

Additionally, the support implemented here is still lacking some features that are needed to make pull diagnostics really work:

• the server has the capability to ask the client to refresh diagnostics that we need to respond to: https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#diagnostic_refresh
• have a separate request for workspace diagnostics (which should be streamed into the picker using nucleo): https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#workspace_diagnostic
• allow incremental updates (so the server doesn't resend diagnostics that didn't actually change)
• VScode allows language plugins to configure whether to only pull diagnostics on save. With Track long lived diagnostics inside helix #6447 that may work quite well. It may make sense to offer a per-language config option for that.

I think the last two points are pretty optional but the first two capabilities seem pretty essential to me.

[pascalkuthe]

Instead of figuring out of the server has sent a publish diagnostic notification we can simply assume the server will not send them if it has the pull diagnostic capability set (the server will then look at our capabilities and make a decision based on that)

[woojiq]

@pascalkuthe thanks for the extensive answer. I agree with you. I'm going to rework this PR after the event system is deployed. If for some reason I miss this part, feel free to ping.✌️

[4ndv]

@woojiq looks like the event system was merged recently

[woojiq]

@woojiq looks like the event system was merged recently

I will have a look. What language server do you use that you need pullDiagnostic, ruby-lsp?

[4ndv]

@woojiq looks like the event system was merged recently

I will have a look. What language server do you use that you need pullDiagnostic, ruby-lsp?

Planning to, yes. Right now I'm using lsp mode in rubocop, but it lacks some stuff

[woojiq]

Unfortunately, I am no longer interested in it for two reasons:

1. none of language servers I use (clangd, rust-analyzer) support this;
2. much more work need to be done than I thought

Although implementing this probably shouldn't be that difficult since almost all the building blocks for working with LSP are already in the codebase.

I might come back to it in the summer, but point 1 is crucial. Sorry for the false expectations.

[David-Else]

Seems from version 3.0.1 vscode-eslint uses textDocument/diagnostic: hrsh7th/vscode-langservers-extracted@859ca87#commitcomment-142170236