Skip to content

Add support for global project settings #431

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

Closed
jonhoo opened this issue May 15, 2018 · 9 comments · Fixed by #1013
Closed

Add support for global project settings #431

jonhoo opened this issue May 15, 2018 · 9 comments · Fixed by #1013

Comments

@jonhoo
Copy link

jonhoo commented May 15, 2018

Currently, the file pointed to by settingsPath (by default) is a per-project .vim/settings.json. However, in many cases, it makes sense to define some settings globally (e.g., build_on_save). It'd be nice if LanguageClient read ~/.vim/settings.json and ./.vim/settings.json, and merged them (with the latter overriding the former).

Second, it'd be fantastic if we could have support for per-language settings similar to what exists in VSCode. For example, if my settings.json contains rust.build_on_save, the setting build_on_save should only be sent if the language is rust.

@dryya
Copy link

dryya commented May 15, 2018

I very much support this idea, but think it would be better to follow the XDG spec. I couldn't find any discussion of how .vim was selected in #179 , but I don't think it's the most intuitive folder name - neovim doesn't even read any files from ~/.vim, as far as I can tell. Trying to read $XDG_CONFIG_HOME/nvim/settings.json, then if not defined ~/.config/nvim/settings.json, and then if that does not exist ~/.vim/settings.json sounds like a good option. I honestly think ~/.vim should be removed altogether, but that would probably break some people's configs by surprise.

In terms of per-project options, it think it might also make sense to just save it as ./.LSPsettings.json or something like that, similar to the way pylint does it, where I believe it checks for ./.pylintrc for per-project settings.

(If the file name is changed, it would of course make sense to change the name of the global settingsPath file to LSPsettings.json or whatever is selected as well).

@autozimu
Copy link
Owner

autozimu commented May 15, 2018 via email

@jonhoo
Copy link
Author

jonhoo commented May 15, 2018

Ah, I did not know about the language-specific features! That's great! It'd probably be good if this feature was documented somewhere though.

I'm not sure exactly what you mean about specifying them when giving commands? And would this still then merge the settings with the per-project ones, and make the per-project settings override the global ones when some setting is specified by both?

@autozimu autozimu changed the title Add support for global and per-language settings Add support for global settings May 15, 2018
@autozimu autozimu changed the title Add support for global settings Add support for global project settings May 15, 2018
@Anrock
Copy link

Anrock commented May 16, 2018

Somehow related question: is there any doc on what options are allowed in this settings.json file? Can't find anything on Google. Is it related to LSP itself or is it LanguageClient-neovim specific?

@dryya
Copy link

dryya commented May 16, 2018

It is related to the specific options provided by servers. For example, here are the RLS options: https://github.com/rust-lang-nursery/rls#configuration

@jonhoo
Copy link
Author

jonhoo commented May 16, 2018

(note, however, that that list is non-exhaustive)

@jonhoo jonhoo closed this as completed May 16, 2018
@jonhoo jonhoo reopened this May 16, 2018
@autozimu
Copy link
Owner

specifying them when giving commands

This is an example of achieving global settings by specifying it within commands, https://github.com/cquery-project/cquery/wiki/Initialization-options

I don't think it will be applicable to all settings and all language servers, but thought it might be helpful to some use cases.

@jonhoo
Copy link
Author

jonhoo commented Feb 24, 2019

@autozimu in particular, as one data point, Rust's RLS does not take any command-line options to configure its behavior. I filed rust-lang/rls#1325

@blahgeek
Copy link

I think it would be great if the language client can

  1. check for project specific settings in current folder, and fallback to global settings if not found
  2. merge the project specific settings with the global setting (override specified fields only)

One use case is that, MSPYLS requires python interpreter path in initialization options, which is different for projects using virtual environment. But there's other settings like cache directory that I want to share across different projects.

For now, I need to copy the whole settings to project folder, and change the settings path using something like https://github.com/embear/vim-localvimrc (not all projects have local per-project settings). Also if I want to change the cache directory, I need to change settings from all projects.

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

Successfully merging a pull request may close this issue.

5 participants