Turn lsp_format_on_save into plugin/client-level settings

[radeksimko]

Firstly thank you for implementing #731 - once configured it works well. 👍

---

That said it took me a while (hours of debugging) to realize that this is Sublime-level option and as such has to be set in the global Preferences.sublime-settings.

The documentation admittedly does mention this and I did actually read it as part of my lengthy debugging process, but it wasn't obvious to me even after reading it.

I suspect the debugging process was particularly painful because of a few facts:

• Sublime can't validate plugin-specific settings in the global context to tell you particular option is (un)expected or (in)valid, it's just something Sublime itself ignores
• Relatedly plugin-level settings is also treated as an arbitrary data structure and the plugin doesn't seem to validate it (possibly to allow backwards compatibility?). It will therefore just ignore lsp_format_on_save in plugin settings.
• I have zero experience with developing Sublime extensions, but I would never have thought that plugins would be allowed to store plugin-level settings in a global namespace.

Would you be open to making this plugin and/or client-level settings, i.e. configurable in LSP.sublime-settings on the root level there, or per each client?

[rwols]

I have zero experience with developing Sublime extensions, but I would never have thought that plugins would be allowed to store plugin-level settings in a global namespace.

Well, it is what it is. There are other plugins that do this for various reasons. For one thing, it allows for some handy tricks, like storing lsp_active in a view for context-aware keybindings.

The important thing about it being a "global" setting is that you can put it in the "settings" dict of your .sublime-project. That way, you can control format-on-save functionality per-project (some clients/companies want auto-format, others perhaps don't).

Relatedly plugin-level settings is also treated as an arbitrary data structure and the plugin doesn't seem to validate it (possibly to allow backwards compatibility?). It will therefore just ignore lsp_format_on_save in plugin settings.

There is no "official" way to get all the key-value pairs: https://www.sublimetext.com/docs/3/api_reference.html#sublime.Settings

Here's a little more information about the order of loading settings: https://www.sublimetext.com/docs/3/settings.html

The thing with plugin-specific settings is that they kind of live on an island on their own. That also means that you cannot modify them per-project. This plugin solves that by looking at an "LSP" key in the "settings" dict of the .sublime-project and parsing the value of that key, overriding any "global" LSP.sublime-settings manually in Python code.

Possibly related: #763

[rchl]

There is also relevant discussion from this SublimeText/TrailingSpaces#140 (comment)

Basically, it would make sense to support project-specific overrides for all settings (or at least those that make sense to have overrides for) by having lsp.[setting-name] keys in project override LSP [setting-name] keys (the . (dot) being the separator in namespace.setting naming scheme).

[rwols]

With #1087 merged, lsp_format_on_save is now a plugin setting. I think it makes sense to keep it a plugin setting. We should only care about the existence of a documentFormattingProvider. Whether that comes from language server X or language server Y should not matter.

[radeksimko]

That's great, thank you!