Support for publishDiagnostics LSP flow messages

[olifink]

I have checked that this feature is not already implemented

• This feature does not exist

Use case

As I understand you currently only support pullDiagnostics from the LSP. Do you have plans to also support publishDiagnostics eventually/soon-ish?

Description

I'm currently integrating ruby-lsp with Nova editor, and I see no way to integrate pullDiagnostics requests, but their LanguageClient already supports the publishDiagnostics flow with proper document notification messages on changes.

Implementation

(up to you)

[vinistock]

Thank you for the feature suggestion! We switched to using pull diagnostics because it allowed us to improve the way we lazy parse documents in the server.

I don't think there's a reason to support both pull and publish diagnostics, but if we can find a way to maintain performance using publish diagnostics that should be fine. If anyone is interested in looking into, I think we can do the following:

1. Stop processing pull diagnostics
2. When we receive a request for one of the combined automatic features (folding range, semantic highlighting, document symbol, etc), then we can push a rubyLsp/textDocument/diagnostic message into the incoming_queue ourselves to delegate the work
3. When processing the message, instead of sending a response back to the editor, we send a publish notification for the computed diagnostics

That said, pull diagnostics were added to the LSP spec a while ago, so it might make sense for Nova to support it.

[olifink]

Thanks! Yes, I've already opened a request for Nova to support pullDiagnostics. I haven't heard back yet and wanted to understand your side.

I'm coming across situations (both with LSP language server and DAP debug adapter protocol) where implementations on either side (editor and server) don't match up, ie. both editor and server support diagnostics features, but they can't be hooked up being in different optional parts of the protocol.

I'll definitely keep pushing Nova for more complete support of the protocols, so that more language servers work directly more or less out of the box.

But it seems to me that the same situation exists on the server side, ie. the more complete LSP protocol support they have, the more likely they work with other editors out of the box.