feat: add RustOpenDocs command

[Shatur]

Borrowed from simrat39/rust-tools.nvim#188
Uses Open external documentation extension.

[Shatur]

I would rename CargoReload into RustReloadWorkspace for consistency. What do you think?

[Shatur]

CI fails on unrelated file. Should I apply formatting for it too?

[justinmk]

out of scope for this project, which is just a collection of configs.

[Shatur]

out of scope for this project, which is just a collection of configs.

@justinmk But why? But we already have CargoReload and ClangdSwitchSourceHeader commands. And there is a special field in this plugin called commands.

[justinmk]

But we already have CargoReload and ClangdSwitchSourceHeader commands.

Those should be removed. This repo is not intended to be an application layer for every single LSP server, it's only a way to get Nvim LSP working with common LSP servers.

[Shatur]

Those should be removed.

@justinmk Where it was discussed?
I was the one who introduced ClangdSwitchSourceHeader command for clangd back then: #263
And recently there was a fix which brings commands back into documentation: #1798
(we have plenty of them)

[justinmk]

The readme used to make this more clear, but changes since then have made it less clear. I'll update the readme. This repo is not an endless source of random features. It is a collection of configs to lower the friction for getting started with Nvim LSP. That's it. Anything beyond that is out of scope and is a bigger maintenance cost than intended.

[Shatur]

The readme used to make this more clear, but changes since then have made it less clear.

Then why @mjlbach fixed commands parsing for documentation? And why we even have an interface for them?

It is a collection of configs to lower the friction for getting started with Nvim LSP

All plugin commands (7 servers currently support them) use LSP queries from LSP extensions. And they are all a few lines of code. I don't see how it harms, but working with C++ without ClangdSwitchSourceHeader would make very inconvenient. I don't think users should create a separate plugin for each server extensions. This kind of removes the point of nvim-lspconfig.

[justinmk]

ClangdSwitchSourceHeader would make very inconvenient. I don't think users should create a separate plugin for each server extensions

I agree. But users also shouldn't need to learn separate commands for each language. There needs to be a generic interface (which does not need custom config for each LSP), or it's out of scope for Nvim LSP.

No idea what ClangdSwitchSourceHeader does, but I've never needed it. This kind of special-case thing is not something we can maintain for 100s of language servers.

[Shatur]

But users also shouldn't need to learn separate commands for each language. There needs to be a generic interface

But it's unavoidable because each language server provides its own extensions. And all commands mentioned in README, example.

No idea what ClangdSwitchSourceHeader does, but I've never needed it. This kind of special-case

It does what the command says - switches between header and source file. Most people use it, this feature available in any C++ IDE. It's not a special case. And we can't apply something like this to other languages because they don't need it.

The only interface we could have - special commands specific to language server. And we do have such interface currently. Is there a place where their removal was discussed?

[justinmk]

But it's unavoidable because each language server provides its own extensions. And all commands mentioned in README, example.

On the contrary, extensions like experimental/externalDocs very well can be auto-completed via a generic mechanism, maybe something like :LspExt <tab>. Happy to talk about that in https://github.com/neovim/neovim

And we can't apply something like this to other languages because they don't need it.

https://github.com/tpope/vim-projectionist provides a generic mechanism for that, useful for all kinds of languages. Which is another strong reason why this kind of command doesn't belong in a collection of LSP configurations.

Is there a place where their removal was discussed?

nvim-lspconfig since the beginning had a limited purpose. Maintaining that limited scope isn't up for discussion.

[Shatur]

On the contrary, extensions like experimental/externalDocs very well can be auto-completed via a generic mechanism, maybe something like :LspExt .

For each extension we need a separate logic which depends on the LSP extension. But I like the idea of ​​having sub-commands instead of individual commands, although that's a separate topic.

https://github.com/tpope/vim-projectionist provides a generic mechanism for that, useful for all kinds of languages.

I can hardcore needed LSP queries and language server configuration in my dotfiles myself, but we have nvim-lspconfig to make this features easily accessible for users. People who work with clangd usually expect to have something like ClangdSwitchSourceHeader, especially when they migrating from VSCode or CLion.

nvim-lspconfig since the beginning had a limited purpose. Maintaining that limited scope isn't up for discussion.

I didn't propose to discuss the scope of the project. What I saying is that we always had the commands feature in this plugin. And you suggested to remove it. This is what I think worth to discuss. Because language server commands always was a scope of this plugin.

[lithammer]

It does what the command says - switches between header and source file. Most people use it, this feature available in any C++ IDE. It's not a special case. And we can't apply something like this to other languages because they don't need it.

Isn't that basically the definition of a special case though? The fact that this doesn't exist for any other language (outside the C-family obviously) or isn't part of the LSP spec? You have to remember that this isn't an IDE, it's an LSP client.

The only interface we could have - special commands specific to language server. And we do have such interface currently. Is there a place where their removal was discussed?

I think the point of custom command was so that you could easily extend your own configuration with them, not to maintain an exhaustive list here.

[justinmk]

On the contrary, extensions like experimental/externalDocs very well can be auto-completed via a generic mechanism, maybe something like :LspExt .

For each extension we need a separate logic which depends on the LSP extension

If langserver extensions aren't discoverable from their API (or via URL, package.json, etc), then we aren't going to enumerate them manually in nvim-lspconfig. That is not a maintenance cost we can carry.

People who work with clangd usually expect to have something like ClangdSwitchSourceHeader, especially when they migrating from VSCode or CLion.

Feature parity with vscode or other IDEs is out of scope for nvim-lspconfig. Nvim LSP is a framework, and nvim-lspconfig is a way to help users get started quickly. We cannot and will not maintain feature parity with vscode (which itself depends on third-party extensions for each LSP) in nvim-lspconfig.

[Shatur]

Isn't that basically the definition of a special case though?

What I mean is that common for C++ workflow.

I think the point of custom command was so that you could easily extend your own configuration with them
That is not a maintenance cost we can carry.

Then why we already have some language server specific commands? It's confusing.

and nvim-lspconfig is a way to help users get started quickly. We cannot and will not maintain feature parity with vscode

I didn't mean the we should have feature parity with VSCode. What I mean is to get started with C++ it's nice to have the ability to switch between source and header too. It's just a few lines of code. I don't see how it hurts, but it could be frustrating for users to copy them from other people's configs.

[Shatur]

Opened #1937.

[TamaMcGlinn]

This kind of special-case thing is not something we can maintain for 100s of language servers.

Isn't the whole point of open-sourcing, that you don't have to? @Shatur has provided the necessary code. If you can't manage to review code and approve it, perhaps you should give more people the ability to merge? Anyway, the open-source answer to this problem is forking. So here is my fork, where I will approve everything unless I notice it is broken. Feel free to direct people there if you don't feel like merging other features.

[justinmk]

Tracked in Nvim core at neovim/neovim#28329