rust-analyzer documentation lists wrong config options

[matklad]

The "available settings" section is incorrect here:

https://github.com/neovim/nvim-lspconfig/blob/master/doc/server_configurations.md#rust_analyzer

It lists settings which aren't actually supported by nvim.

If I am reading the following code correctly:

https://github.com/neovim/nvim-lspconfig/blob/ec7119b166b16e681f663fcbf16b7139b38172ae/scripts/docgen.lua#L164-L174

The way this section gets populated is by scrapping VS Code extension's package.json for settings. In the case of rust-analyzer, those settings apply to the VS Code extension itself, and not necessary to the language server binary. For example, rust-analyzer.server.extraEnv is used by VS Code plugin here to spawn the rust-analyzer process itself. As neovim doesn't have custom client-side code to honor this setting, it doesn't actually work and cause user confusion (see, eg, https://users.rust-lang.org/t/neovim-vs-blocking-waiting-for-file-lock-on-build-directory/72188).

To get the list of settings which are supported by rust-analyzer itself (and not by vs code extension), you can run

$ rust-analyzer --print-config-schema

I wish there was a server-independent way to specify config schema, but, as far as I know, there isn't one yet

[mjlbach]

Hi @matklad,

Thanks for reaching out. I currently have plans to remove all auto-generation of settings documentation (see https://github.com/neovim/nvim-lspconfig/pull/1656), because, as you pointed out, often these include a mix of server settings (initializationOptions and workspace/didChangeConfiguration settings and vscode specific options).

I'll just go ahead and merge that PR unless you have an alternative suggestion, as most servers that are not rust-analyzer don't provide a command to extract the language server specific schema.

The PR template is intentionally over fit to helping users troubleshoot server issues, we (used to) get an extremely high number of low quality bug reports, which the strict template has improved. I'm always available on matrix to be pinged about issues from server developers such as yourself.

[matklad]

Yeah, merging #1656 makes sense! And yeah, totally agree that it isn't worth it to have a dedicated docugen specifically for rust-analyzer --print-config-schema -- this isn't going to scale to all of the servers available out there, unless this flags becomes a de-facto standard protocol extension.

Still, I think there's an opportunity for optimization here: rust-analyzer has a way to automatically get correct config schema, and it certainly would be nice if the users got neovim specific completion/documentation, the same way VS Code users get it. It'd be cool if this problem was solved in a decentralized fashion -- while burdening neovim/lsp-config with ra-specific concerns doesn't feel right, having that in something like https://github.com/simrat39/rust-tools.nvim would make sense (cc @simrat39).

[matklad]

Just in case someone finds this helpful, human-readable, editor-agnostic documentation about ra settings is here: https://rust-analyzer.github.io/manual.html#configuration (that doc could use some improvement though, as always)

[mjlbach]

unless this flags becomes a de-facto standard protocol extension

This would be great for us, at least. I can file an issue upstream with the specification to ask about standardizing metadata associated with options, but my gut tells me MS will not care since it is not a proposal that would benefit vscode.

It'd be cool if this problem was solved in a decentralized fashion -- while burdening neovim/lsp-config with ra-specific concerns doesn't feel right, having that in something like https://github.com/simrat39/rust-tools.nvim would make sense.

I totally agree, lspconfig is only meant to be a catch-all plugin for users that don't want/care about deep customization of server options. I'm hoping more language specific plugins pop out that can bear the burden of manually updating schema, or adding server specific GHA workflows to extract the schema (in the case of rust)

[matklad]

but my gut tells me MS will not care since it is not a proposal that would benefit vscode.

You are not wrong, see https://github.com/microsoft/language-server-protocol/issues/467 :-) It might be the case that, in principle, we can create a de-facto standard without getting into de-jure spec, like happened with offsetEncoding.

[mjlbach]

You are not wrong, see https://github.com/microsoft/language-server-protocol/issues/467 :-) It might be the case that, in principle, we can create a de-facto standard without getting into de-jure spec, like happened with offsetEncoding.

It would be nice if we had a community led way about coordinating these things, perhaps a matrix channel? We could invite several server/client authors

[mjlbach]

Removed all package.json

[simrat39]

Yeah, merging #1656 makes sense! And yeah, totally agree that it isn't worth it to have a dedicated docugen specifically for rust-analyzer --print-config-schema -- this isn't going to scale to all of the servers available out there, unless this flags becomes a de-facto standard protocol extension.

Still, I think there's an opportunity for optimization here: rust-analyzer has a way to automatically get correct config schema, and it certainly would be nice if the users got neovim specific completion/documentation, the same way VS Code users get it. It'd be cool if this problem was solved in a decentralized fashion -- while burdening neovim/lsp-config with ra-specific concerns doesn't feel right, having that in something like https://github.com/simrat39/rust-tools.nvim would make sense (cc @simrat39).

rust-tools now shows the server specific settings!

Its not automated right now but hopefully will be soon.

https://github.com/simrat39/rust-tools.nvim/wiki/Server-Configuration-Schema https://github.com/simrat39/rust-tools.nvim/commit/a4063d8dda78cf43cde93a264a5ae1dad8811b52

[nemethf]

It would be nice if we had a community led way about coordinating these things, perhaps a matrix channel? We could invite several server/client authors

Did this discussion take place? What was the outcome?

[mjlbach]

No, I just removed the docgen of settings.

[nemethf]

If it's ever going to happen, I'm interested. Thanks.

[mjlbach]

Are you a language server author or the author of a language server client?

[nemethf]

I'm a regular contributor to Eglot (an LSP client for Emacs), and wrote some simple servers as well. (And have very minor contributions to proper servers as well.)