Upstream :Lsp commands from nvim-lspconfig about neovim

[lewis6991]

One benefit (and design requirement) of vim.treesitter.language.add is that it can be called from multiple sources. I think that requirement should apply to LSP too, i.e. servers can be specified in multiple sources: config, plugins, etc.

[lewis6991]

Just to throw in another idea.

I've been debugging some LSP stuff and wondering whether something like this would also be useful:

vim.lsp.log.set_level(vim.lsp.log.levels.DEBUG)
-- vim.lsp.log.set_format_func(vim.inspect)

api.nvim_create_user_command('LspLog', function()
  local log_path = vim.lsp.get_log_path()
  vim.cmd.split(log_path)
end, {})

Something like this could reduce friction with LSP issues, since atm, getting the log file is rather tedious, and can quickly solve certain kinds of issues. Just an idea. A similar treesitter analogue is :InspectTree.

With that said, the LSP logging does need some improvements because currently the log is shared between all servers and nvim sessions and grows indefinitely unless it is manually cleared.

[justinmk]

Nvim core would need the concept of "registering" or "managing" a client without it being started. For example, a vim.lsp.register API that makes Nvim aware of a client configuration without actually starting it.

Do we only need a way to "define" clients and add them to a list, or is there more involved (such as lifecycle, cleanup, ... which is the usual unpleasantness implied by a "registry")? Maybe vim.lsp.add_client() or vim.lsp.def_client() could be the name. Or vim.lsp.config()

[lewis6991]

+1, but I would prefer we add :Lsp with stop, restart and info sub-commands.

Ah sorry, didn't read OP fully, that's what you are already proposing.

[lewis6991]

Nvim core would need the concept of "registering" or "managing" a client without it being started. For example, a vim.lsp.register API that makes Nvim aware of a client configuration without actually starting it. This same functionality would be needed for :LspStart as well, if we want to include that.

Note we already have vim.treesitter.language.register/add which serves a similar purpose, would be nice if we could mirror that, or have them align.

[justinmk]

we already have vim.treesitter.language.register/add which serves a similar purpose, would be nice if we could mirror that, or have them align.

Definitely. gpanders mentioned vim.lsp.config, I wonder if that can be the interface for "defining a client". See also #24054

[clason]

We definitely want to support "language server plugins" as a first-class use case here (not for every server, mind you, but for those that require more work to set up or have custom commands that are out of scope for core).

[gpanders]

Something like this could reduce friction with LSP issues, since atm, getting the log file is rather tedious

Not opposed to it, but just to point this out: :checkh lsp prints the path to the log file and you can use gf or <C-W>f on that to open it. It's admittedly not the most straightforward, but it's not too bad in a pinch.