can :LspInfo (:checkhealth lspconfig) show more detailed info?

[justinmk]

Description

#3375 removes an undocumented config.lspinfo extension point that was intended to allow config-specific augmentation of the LspInfo report. Can information such as tool versions be derived from LSP client info and/or server responses instead?

Example use case: #1693 which wants to report the "project file".

Proposal

• ✅ print the <cmd> --version result. 3375, 3383 3388
• The client has workspace/configuration, so it knows its own configuration. Why can't LspInfo ask the cient for this kind of info?
• The client can ask the server for workspace/workspaceFolders, which sounds related to
• the Nvim client can store info from initialize, workspace/didChangeConfiguration, etc. If that info is available via e.g. vim.lsp.get_clients(), then LspInfo can use it. If info isn't available via vim.lsp.get_clients(), then question is why, and should it be?

suggested by @glacambre :

Could a new field be added to language server configurations listing additional workspace/executeCommand requests that would be nice to perform on :LspInfo? Then the als' configuration could have als-project-file in that field, and Neovim could display the result of that request as a string in LspInfo's buffer.

Maybe vim.lsp.Client could have a statusCmds: string[] field which defines how "status" can be reported by a server.

[glepnir]

Can information such as tool versions be derived from the LSP server response instead?

No way lsp spec doesn't have a method to get information of server instead :!clangd --version not enough ? the only usage of config.lspinfo is in hls..so i think you don't need worry about there..

[justinmk]

updated proposal. clangd --version requires config-specific stuff and doesn't address things like #1693 which wants to report the "project file".

[glepnir]

aha okay so can we add a health field instead of lspinfo in configs ? this can lead more users to pay attention to checkhealth . default use info level is enought health_info(table.concat(configs.health()), '\n')

[justinmk]

add a health field instead of lspinfo in configs

No. That wouldn't be any different than the existing config.lspinfo field.

What I'm asking is first, what info does the LSP client already know, that can be displayed by checkhealth. Does workspace/workspaceFolders report anything useful?

And why isn't root_dir enough to provide what was intended in #1693 @TamaMcGlinn ? root_dir already defines the *.gpr pattern, so why can't checkhealth use root_dir to say which pattern matched, then report that?

[glacambre]

so why can't checkhealth use root_dir to say which pattern matched, then report that?

Because there could be multiple *.gpr files in a same root directory, so root_dir isn't enough to know which one is being used by the ada language server. In such a case, clients will often use workspace/didChangeConfiguration to select a .gpr file, but storing and re-displaying that information would not work in cases where the client let the server choose a .gpr file.

[justinmk]

Or maybe just "version" can be added to the list of options in try_format_version.

yes, that is the idea :) PR welcome...

since it ends up printing a very large 'help' page (that gopls spits out)

we should truncate the output. Done: #3388

[spenrose]

Added version for gopls. #3386

Probably need to add status command to each config.

[justinmk]

Probably need to add status command to each config.

No. If server commands can't be bothered to provide --version, we aren't going to maintain special workarounds for them. They can either provide --version or we will report "failed to get version". It is idiotic that they don't provide --version, or some other common arg to get version/status info.

[justinmk]

Could :LspInfo also list root_dir?

Thanks, that was a regression. Fixed in #3402

[nogweii]

Something I'd like to see is whether an LSP has document formatting support. I have a BufWritePre hook that will format the buffer using all available LSPs. Sometimes that doesn't behave in the way I want (e.g. conflicting styles) so I'd like to know which LSPs are being triggered.

I'm not sure this should be included in lspconfig or if a new API should exist to allow end-users to configure additional status functions to be ran for all language servers.