docs: how to make diagnostics work with ruby-lsp

[cefigueiredo]

ruby-lsp >= 0.2.2 does not implement textDocument/publishDiagnostic specification that is supported by Neovim, implementing only the textDocument/diagnostic. This commit presents a workaround to make ruby_ls send textDocument/diagnostic requests to the Server, and treat the response like it was for a textDocument/publishDiagnostic event.

[glepnir]

I think it would be better in ruby-lsp doc or somewhere then we can use that link .

[cefigueiredo]

I believe the folks on ruby-lsp might be interested in linking instructions of how to integrate to other editors besides vscode, that they already maintain.

However, I understand that is also important update the usage instructions present on nvim-lspconfig docs that are accessible from the editor with :h lspconfig-all. I identified the need for the update, because the current instructions would not completely enable the diagnostics feature for a more recent ruby-lsp version.

More specifically since ruby-lsp v0.2.2 that according to Shopify/ruby-lsp#242 dropped support to textDocument/publishDiagnostics natively used by neovim, in favor of only maintain the textDocument/diagnostic from LSP v3.17 specification that requires the client to decide when to pull for diagnostics.

[glepnir]

I think the point is we should implement handler for textdocument/diagnostic and workspace/diagnostic in core..

[glepnir]

merge this first . but please create an issue in core for create handler for textdocument/diagnostic

[smarquez1]

Hey @cefigueiredo thank you for the instructions. I created a core ticket yesterday to add the textDocument/diagnostic feature to neovim using your explanation on the issue. Let me know if you want to add anything!

[technicalpickles]

Would it be reasonable to just added the recommended workaround to lua/lspconfig/server_configurations/ruby_ls.lua rather than documenting the workaround? That way, users get a better out of box experience until there is support in neovim itself.

I can think of a few ways to detect the older versions, but they are kinda dirty. ruby-lsp doesn't have a --version flag unfortunately. It would be in someone's Gemfile.lock if they have it for their project, but that isn't always how it's installed.

Maybe an option to work for new vs old ruby-lsp?

[cefigueiredo]

Would it be reasonable to just added the recommended workaround to lua/lspconfig/server_configurations/ruby_ls.lua rather than documenting the workaround? That way, users get a better out of box experience until there is support in neovim itself.

I don't believe it would be reasonable. Because it would either be too invasive for the users or just not work on most cases.

This lua/lspconfig/server_configurations/ruby_ls.lua only sets the default configuration object that lsp config merges with the settings the user send when declaring the lsp client, on

nvim_lsp["ruby_ls"].setup {
  on_attach = function(_, bufnr)
    -- user custom keymaps
  end
}

nvim-lspconfig does not setup any key mappings in the user editor. It's a premise on lspconfig to the neovim user pass to nvim_lsp["CLIENT"].setup a table structure with a on_attach function that runs when the lsp client is bound to a buffer, and it's where the user declares its own keymap bindings.

The table provided by the user is merges onto the default settings of the lsp client, replacing the table keys that match.

So, if the default settings for ruby-lsp declares its own on_attach , it would be replaced by the user's on_attach, and the user would still be unaware of how to do the workaround without the instructions in the doc for the ruby-lsp client.

To make the server client default settings declare a function to be run when the client is loaded in the buffer, but not affecting the on_attach, it would demand a complete new feature that is not the proposal for this PR, even because currently only ruby-lsp demands such workaround.

The ideal, is neovim-core support the PullDiagnostic feature from LSP specification out of the box, when that happens, the workaround would not be needed anymore. But this will take a while to enter the core roadmap.

Until then, I believe that the instructions in the doc would be the more reasonable option.

[justinmk]

If there's a bug in Nvim LSP client, check Nvim 0.10 (development version) and say how to reproduce the issue. Adding tons of special-case notes and configs to nvim-lspconfig is out of scope.