refactor: use vim.lsp.start instead of vim.lsp.start_client #3450
Conversation
MariaSolOs
requested review from
lewis6991 and
gpanders
and removed request for
glepnir
|
minimum compatible version is 0.9 now unless minimum bump to 0.10 but there still have 0.9 user |
Correct me if I'm wrong but |
|
yes. i remember wrong version just tried on 0.9 |
Thanks for checking! |
| --- @param root_dir string | ||
| --- @param client vim.lsp.Client | ||
| --- @param single_file boolean | ||
| function M:_attach_after_client_initialized(bufnr, new_config, root_dir, client, single_file) |
There was a problem hiding this comment.
When neovim start with reads the session it may contain multiple projects. This needs to be checked after the first server start.
I think this PR is better to simply replace vim.lsp.start_client by vim.lsp.start rather than refactor other functions. our goal is more to add support in the core. If the overall work is good now, it is OK to leave it this way without too much change.
There was a problem hiding this comment.
The logic of _attach_or_spawn is:
- Call
lsp.buf_attach_client(which neovim does insidevim.lsp.startso no need to do it here) - Add the client to the
_clientscache - Send a
workspace/didChangeWorkspaceFoldersnotification if the server supports it.
The implementation in this PR keeps 2 and 3, event after the server is first initialized. Or are you referring to something else?
There was a problem hiding this comment.
vsplit has two buffers in two projects. run mksession and then starts neovim with -S session.vim. The first buffer triggers FileType to start a server. Note that this is an asynchronous ,server that needs initialization time. At this point you are not sure if the server supports workspacefolder. But the second buffer has triggered FileType again. The embed process is processed continuously. So the second buffer should wait for the server started by the first buffer to complete initialization and check whether to connect to it or start a new one.
that's why there have a timer check client.intialized if currently refactor can handle it as expect. ignore me.
There was a problem hiding this comment.
I see. I've replaced the code using the timer by adding this hook to on_init.
There was a problem hiding this comment.
if I remember correctly, this is a hook for modifying the parameters of the server itself. It runs after the root judgment. The problem is that if the server has not initialized the second buffer, the same event loop will run the launch function. Can we know that the first server started supports workspacefolder? Shouldn't there be a synchronous waiting problem here? I have forgotten some of the code here. I simply tested this Pr code and it works as I expected. But I still don't understand the logic here.
glepnir
changed the title
That’s the goal indeed! And the name changes were mostly because I had to stare at the code for a while to understand what it was doing 😅 |
This PR replaces the usage of
vim.lsp.start_clientbyvim.lsp.start, delegating the logic of client reuse to the editor.Also adding support for a
silentoption to prevent error notifications on init.