-
-
Notifications
You must be signed in to change notification settings - Fork 5.7k
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
feat(lsp): support connect via named pipes/unix domain sockets #26032
Conversation
There's nothing written in stone about it, but personally I believe that the more accurate the type annotations, the better (and so I prefer |
The doc generation becomes kinda goofy when using |
runtime/lua/vim/lsp/rpc.lua
Outdated
--- Unix and name on Windows) | ||
--- | ||
---@param pipe_path string | ||
---@return fun(dispatchers: Dispatchers): StartServer? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Feels a bit odd to have a "plural" type like Dispatchers
. I find more intuitive to have a singular vim.rpc.Dispatcher
type and make this parameter a table of those.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I took these types from the private dispatchers that are passed to this function by vim.lsp.start_client
. Not all of them share the same signature, so this type can't be an array of vim.lsp.rpc.Distpacher
, what do you suggest for this case?
--- | ||
---@param pipe_path string file path of the domain socket (Unix) or name of the named pipe (Windows) to connect to | ||
---@return fun(dispatchers: vim.lsp.rpc.PrivateDispatchers): vim.lsp.rpc.StartServer? #function intended to be passed to |vim.lsp.rpc.start_client| or |vim.lsp.start| on the field cmd | ||
function M.domain_socket_connect(pipe_path) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe something like:
function M.domain_socket_connect(pipe_path) | |
function M.connect_to_pipe(pipe_path) |
Merging it into connect
could also be an option, if we change the args to opts
and distinguish based on the keys. With a type(opts) == "table"
check we could even make it backward compatible (if it is a string, it's a host name)
cc @justinmk do you have inputs on this?
@TheLeoP could you also add an entry to the news.txt? @MariaSolOs Do you have any other inputs on this? Otherwise I'd go ahead and merge this. We can still follow up with renaming the method before it get's released. |
Left some minor comments but it LGTM. |
Is the entry on news.txt ok? |
@TheLeoP it looks like some of the test failures are introduced by this PR. Could you take a look? |
@mfussenegger Sorry, I hadn't realized. I'll look into it. |
@TheLeoP sorry I haven't realized that you had fixed the test failures. Could you resolve the conflicts and then ping me, I'll then merge the PR |
@mfussenegger done :3. The current failling test may have something to do with the fact that I rebased in top of master? Because I dind't touch any c code in this PR |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like a great feature. I've left some minor style suggestion comments. You'll also need to fix linting errors as checked by CI.
runtime/lua/vim/lsp/rpc.lua
Outdated
---@param callback fun(err: lsp.ResponseError|nil, result: any) Callback to invoke | ||
---@param notify_reply_callback (function|nil) Callback to invoke as soon as a request is no longer pending | ||
---@return boolean success, integer|nil request_id true, request_id if request could be sent, `false` if not | ||
---@param params (table?) Parameters for the invoked LSP method |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
---@param params (table?) Parameters for the invoked LSP method | |
---@param params (table|nil) Parameters for the invoked LSP method |
And for other many places: see https://github.com/neovim/neovim/blob/master/CONTRIBUTING.md#lua-docstrings
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought that using this syntax for optional values was preffered over the old |nil
. Is it not?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Throughout neovim codebase, table|nil
is used instead of table?
But if you meant an optional parameter, it should be @param params? table
(without nil).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Throughout neovim codebase, table|nil is used instead of table?
Remember that Neovim's codebase is vast and written over years. Guidance can change without wanting to add churn by rewriting all old code. Nevertheless, new(ly touched) code should follow current guidance (:h develop
; I don't think we've explicitly formalized this specific aspect -- @lewis6991 @mfussenegger @gpanders @MariaSolOs ?).
In this specific case @param params? table
is indeed correct (no parens!)
The link problem is because I used a commit message that is not valid for the CI. Is it possible to squash all the commits into a single commit when merging to handle this? I'm not very well versed with git, so I didn't know of other ways of modifying past commit messages. |
You can squash the commits into one using "interactive rebase". And then push-force. https://github.com/neovim/neovim/blob/master/CONTRIBUTING.md#pull-requests-prs |
But we can also squash-merge if the PR should just be a single commit. |
I think it's ok for this PR to be a single |
The generated vimdoc still contains some mess and incorrect formatting due to the LuaCATS-vimdoc incompatibility, but this something |
This would solve #26031.
This PR is functional, but (since this is my first PR to the project), I would like to receive feedback regarding things like:
Should I check possibly nil values, if yes, which is the appropiate way to show this erros to the user (is usingerror
preffered over something likevim.notify
using the error log level?).vim.lsp.rpc.connect
to something regarding tcp?)The policy regarding lua typings (is a specific type likefun(dispatchers: Dispatchers): StartServer?
prefered over a general one likefunction
? Is it the oposit way because of how docs are generated?) (as fas as I can tell, neither CONTRIBUTING.MD nor :help dev-doc-lua talk about this).vim.schedule
on thewrite
transport as a workaround because, on my tests using Powershell Editor Services, Neovim sended the initialization requets before the pipe connection was stablished.I think that, ideally,public_client(client)
should be returned from inside the callback onpipe:connect
, but I'm not sure if I'm using the previously existing functions in an unexpected way. (Since I'm usingvim.schedule
here, I also had to add it to the test)Edit:
I'm also not sure about how to test if the method received isinitialize
because of thevim.schedule
thing :/Turns out that busted supports async testsNevermind, it looks like async test aren't supported currently