Upstream :Lsp commands from nvim-lspconfig

[gpanders]

This is a tracking issue to either upstream the :LspStart, :LspStop, :LspRestart, and :LspInfo commands from nvim-lspconfig or determine formally if those features are not wanted.

:checkhealth lsp does a lot of what :LspInfo does, but is not a complete replacement. In #18476 (comment), @mfussenegger mentioned:

:lsp / :LspInfo: LspInfo currently does more than just printing all clients, it also prints all not started yet. It can do that because lsp-config currently includes the "managing clients" functionality. I think the first step we have to do to bring anything like that into core is to move the manager component.

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.

I do not think we should include :LspInfo directly, but its functionality should be integrated into :checkhealth lsp.

If we do add :LspStart and/or :LspStop, I propose they be added as :lsp start and :lsp stop and promote :lsp to a first class command (note, this is a different interface thn the one proposed in #18476).

cc @mfussenegger

[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]

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

[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.

[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).

[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.

[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.