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
fix(zls): use workspace zls.json if available #2944
base: master
Are you sure you want to change the base?
fix(zls): use workspace zls.json if available #2944
Conversation
Language server config is read from `zls.json`. By default common global and user config directories are searched. However, this omits per-project configuration, which can be available in the workspace dir. We already look for `zls.json` to determine root dir, but we don't use it when starting the language server. This change appends `cmd` with `--config-path "zls.json"`, which uses the file when it's available and fall-backs to default logic when file is not available.
@@ -2,7 +2,7 @@ local util = require 'lspconfig.util' | |||
|
|||
return { | |||
default_config = { | |||
cmd = { 'zls' }, | |||
cmd = { 'zls', '--config-path', '"zls.json"' }, |
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.
why we don't check zls.json first build a cmd
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.
We don't really have to, since zls
goes back to using global config if a specified config file does not exists, but we can.
Would you rather have cmd
as a function that checks if zls.json
exists in workspace and and then generates command based on that?
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 is fine if the server can fallback. Just wondering if it might bother some newbies.
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 tried looking into how to provide a function for default_config.cmd
, but couldn't find it, does it always have to be a table?
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.
nope it can be a function.
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'm struggling a bit here.
Tried providing a function instead of a table and printed the arguments, which got me:
{
notification = <function 1>,
on_error = <function 2>,
on_exit = <function 3>,
server_request = <function 4>
}
I then tried looking for these function names in source, but got unrelated stuff or in case of server_request
even no results at all.
Tried looking through docs again, but they only seem to contain an example for table as well:
- {cmd} `list[string]`
a list where each entry corresponds to the blankspace delimited part of
the command that launches the server. The first entry is the binary used
to run the language server. Additional entries are passed as arguments.
The equivalent `cmd` for:
foo --bar baz
is:
{'foo', '--bar', 'baz'}
So not sure how to do this.
Or should I use on_setup
hook instead?
Could you give some pointers on how this could be implemented?
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.
cmd = function() xxxxxx end
Language server config is read from
zls.json
. By default common global and user config directories are searched. However, this omits per-project configuration, which can be available in the workspace dir.We already look for
zls.json
to determine root dir, but we don't use it when starting the language server.This change appends
cmd
with--config-path "zls.json"
, which uses the file when it's available and fall-backs to default logic when file is not available.