New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upstream :Lsp commands from nvim-lspconfig #28479
Comments
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 |
This comment was marked as resolved.
This comment was marked as resolved.
Note we already have |
Definitely. gpanders mentioned |
One benefit (and design requirement) of |
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). |
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 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. |
Not opposed to it, but just to point this out: |
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: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
The text was updated successfully, but these errors were encountered: