Skip to content
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

Merged
merged 31 commits into from
Jan 2, 2024
Merged

feat(lsp): support connect via named pipes/unix domain sockets #26032

merged 31 commits into from
Jan 2, 2024

Conversation

TheLeoP
Copy link
Contributor

@TheLeoP TheLeoP commented Nov 13, 2023

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 using error preffered over something like vim.notify using the error log level?).
  • Suggestions for naming the new function (maybe also renaming vim.lsp.rpc.connect to something regarding tcp?)
  • The policy regarding lua typings (is a specific type like fun(dispatchers: Dispatchers): StartServer? prefered over a general one like function? 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).
  • I'm using vim.schedule on the write 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 on pipe:connect, but I'm not sure if I'm using the previously existing functions in an unexpected way. (Since I'm using vim.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 is initialize because of the vim.schedule thing :/
Turns out that busted supports async tests
Nevermind, it looks like async test aren't supported currently

@MariaSolOs
Copy link
Member

The policy regarding lua typings (is a specific type like fun(dispatchers: Dispatchers): StartServer? prefered over a general one like function?

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 fun(param: paramType): returnType).

@dundargoc
Copy link
Member

The doc generation becomes kinda goofy when using fun(param: paramType): returnType though because it has not been written to handle that case.

runtime/lua/vim/lsp/rpc.lua Outdated Show resolved Hide resolved
runtime/lua/vim/lsp/rpc.lua Outdated Show resolved Hide resolved
--- Unix and name on Windows)
---
---@param pipe_path string
---@return fun(dispatchers: Dispatchers): StartServer?
Copy link
Member

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.

Copy link
Contributor Author

@TheLeoP TheLeoP Nov 13, 2023

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?

runtime/lua/vim/lsp/rpc.lua Outdated Show resolved Hide resolved
runtime/lua/vim/lsp/rpc.lua Outdated Show resolved Hide resolved
runtime/lua/vim/lsp/rpc.lua Outdated Show resolved Hide resolved
runtime/lua/vim/lsp/rpc.lua Show resolved Hide resolved
runtime/lua/vim/lsp/rpc.lua Outdated Show resolved Hide resolved
runtime/lua/vim/lsp/rpc.lua Outdated Show resolved Hide resolved
runtime/lua/vim/lsp/rpc.lua Outdated Show resolved Hide resolved
test/functional/plugin/lsp_spec.lua Outdated Show resolved Hide resolved
---
---@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)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe something like:

Suggested change
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?

@mfussenegger
Copy link
Member

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

runtime/lua/vim/lsp/rpc.lua Outdated Show resolved Hide resolved
runtime/lua/vim/lsp/rpc.lua Outdated Show resolved Hide resolved
runtime/lua/vim/lsp/rpc.lua Show resolved Hide resolved
@MariaSolOs
Copy link
Member

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

@TheLeoP
Copy link
Contributor Author

TheLeoP commented Nov 24, 2023

Is the entry on news.txt ok?

runtime/doc/news.txt Outdated Show resolved Hide resolved
@mfussenegger
Copy link
Member

@TheLeoP it looks like some of the test failures are introduced by this PR. Could you take a look?

@TheLeoP
Copy link
Contributor Author

TheLeoP commented Dec 8, 2023

@mfussenegger Sorry, I hadn't realized. I'll look into it.

@mfussenegger
Copy link
Member

@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

@TheLeoP
Copy link
Contributor Author

TheLeoP commented Dec 23, 2023

@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

Copy link
Member

@wookayin wookayin left a 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.

---@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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
---@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

Copy link
Contributor Author

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?

Copy link
Member

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

Copy link
Member

@clason clason Dec 23, 2023

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!)

runtime/lua/vim/lsp/rpc.lua Outdated Show resolved Hide resolved
runtime/lua/vim/lsp/rpc.lua Outdated Show resolved Hide resolved
runtime/doc/lsp.txt Outdated Show resolved Hide resolved
runtime/doc/lsp.txt Outdated Show resolved Hide resolved
runtime/doc/lsp.txt Outdated Show resolved Hide resolved
runtime/doc/lsp.txt Outdated Show resolved Hide resolved
runtime/lua/vim/lsp/rpc.lua Outdated Show resolved Hide resolved
runtime/lua/vim/lsp/rpc.lua Show resolved Hide resolved
@TheLeoP
Copy link
Contributor Author

TheLeoP commented Dec 23, 2023

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.

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.

@wookayin

@wookayin
Copy link
Member

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

@clason
Copy link
Member

clason commented Dec 23, 2023

But we can also squash-merge if the PR should just be a single commit.

@TheLeoP
Copy link
Contributor Author

TheLeoP commented Dec 23, 2023

I think it's ok for this PR to be a single feature commit, but I could also manually squash commits if it's necessary. Is there something else that should be adressed?

@mfussenegger mfussenegger merged commit 3f788e7 into neovim:master Jan 2, 2024
24 of 25 checks passed
@github-actions github-actions bot removed the request for review from folke January 2, 2024 09:08
@wookayin
Copy link
Member

wookayin commented Jan 2, 2024

The generated vimdoc still contains some mess and incorrect formatting due to the LuaCATS-vimdoc incompatibility, but this something gen_vimdoc is responsible for so let's clean up that as a future work. Anyway nice feature!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants