Feature: Add support for named-pipe sockets for LSPs #3509
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Overview:
Previously, ALE assumed that for all linters with
lsp == 'socket'
that the socket referred to byaddress
was a TCP socket. Neovim'ssockconnect
also supports named pipes [1] which have lower overhead than TCP sockets. This pull-request thus adds support for using sockets which are named pipes. The very simple heuristic of checking ifaddress
contains a colon or not is used to determine if the given socket is TCP or a named pipe, in order to maintain backwards compatibility, and to avoid adding an additional configuration option toale#linter#Define
.Tests:
A new test case has been added to
test/test_socket_connections.vader
in order to test named pipe sockets. To support this test, I wrote a very simple named-pipe-based servertest/dumb_named_pipe_server.py
(which is largely copied fromtest/dumb_tcp_server.py
)Documentation:
The documentation has been updated with information about this new feature.
[1] What I'm calling "named pipes" here are not actually named pipes (i.e. the things you'd get from calling `mkfifo`), but unix domain sockets. For whatever reason Neovim's documentation conflates these things (see `:help sockconnect`), so I've just tried to be consistent with their terminology