Add support for global project settings

[jonhoo]

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]

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]

For per project settings, you can already change the path, and it can also be absolute path. I’d rather not change the decent default. For per language server settings, it is supported. Check for the rust example in tests folder. As for global settings, one alternative is pass those settings as parameters when specifying language server commands.

…

On Tue, May 15, 2018 at 09:53 Genevieve Mendoza ***@***.***> wrote: 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 <#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 ~/.confing/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. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#431 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABYt74aZ8hngZWApd4fAbARAQduFrdDjks5tywf6gaJpZM4T_2Xx> .

[jonhoo]

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?

[Anrock]

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]

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]

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

[autozimu]

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]

@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