Provide completions/linting for settings files

[FichteFoll]

Seeing the following image sparked an idea inside me.

PackageDev could analyze a User settings's reference file (notably: parse it and obtain its keys) to provide both completions for the keys and linting of potentially mis-spelled settings.

Questions:

1. How often do packages not expose their settings in a default file like this?
2. Should we provide the couple extra default settings we know of in a separate data storage? And do the same thing for known packags?
3. How to detect syntax-specific settings files? (sublime.find_resources("*.sublime-syntax") and tmLanguage?)

[deathaxe]

All these new syntax highlighting and completion features more and more make PackageDev an essential part of ST as all those features should be accessible not only by package developers. ;-)

1. I think it is quite common for most plugins to expose their default settings in default files. And those who don't might add it, if they learn about it to enable auto-completion, I think.

2. I don't think this is a good idea as this causes cross references between packages, that should not exist. I would prefer to raise an issue on all plugins known not to export settings in a default file.

3. Why do you want to detect syntax-specific files? All keys which can be used in syntax-specific files must exist in one of the default settings files anyway or am I wrong?

[deathaxe]

Thinking about your questions again, I realize some problems with auto-completions.

Packages normally provide a PackageName.sublime-settings file which a user can modify by creating the same file in the User directory. Auto-completion needs to show only settings from the package's default file in this case - quite easy.

But there are plugins or themes (Boxy), which extensively add settings to the Preferences.sublime-settings file. Themes don't use default settings files to provide defaults so far. So auto-completion and linting might be incomplete for Preferences.

Example

In order to support project based settings GitGutter will make use of the Preferences too in the future. I plan to support all settings from GitGutter.sublime-settings file prefixed by git_gutter_ to be added to preferences or project settings. To support your linting an auto-completion feature I would add a Preferences.sublime-settings.

[deathaxe]

The Preferences Editor may provide some examples how to create the completions list for existing settings. It already provides a quite comprehensive and convenient way to modify settings.

[FichteFoll]

You are correct in that this will most likely not work correctly for the general Preferences.sublime-settings file due to the number of different locations where these settings may be read/used and their nature. Key binding contexts come to mind in addition to themes or just packages that depend on their users being able to read a readme (e.g. InactivePanes, which reads all its settings from the view's settings object while providing sane defaults).

Preferences Editor is a very good reference that I tend to continously forget about, so thanks for the explicit mention.

[deathaxe]

Even though auto-completion can't show all settings within the Preferences.sublime-settings today, I would like to see this feature anyway as it eases settings editing. It should even be a standard feature of ST some day.

If people learn about this feature and start liking it, package developers might start supporting it by adding a Preferences.sublime-settings with default values for their package - if this is populated as requirement.

P.S.: I also like VS Code's feature to edit settings by hovering the gutter area of the default file, which uses the comments to provide a context menu with possible values to apply to the user file.

[r-stein]

It may also be good to show the content of the comment above the setting on hovering. (this could be an other PR as the completion)

[deathaxe]

To be able to show the comment of a setting in the popup we'd require to parse all Preference files "manually" as normal text. I saw VS Code doing something like that. It even provides suggestions for values to set based on the comments and seems to merge all Preferences files on the left side.

All of that would require something like the Side-By-Side Settings to pack everything together in a reasonable way, I think.

What I like best with the Side-By-Side Settings package is the approach to provide a general interface to present all the package settings without the need for each package to handle it on its own.

But there are only about 2k downloads for that package. So is it worth the effort?

[deathaxe]

FYI: Just found https://packagecontrol.io/packages/EasySettings

It provides auto-completion in settings files.

[deathaxe]

Any progress on settings completion / settings syntax?

I ask because I recently had a look into EasySettings as it throws stupid errors sometimes with the result of completely rewriting it at the moment. Maybe the result could end up in a PR for PackageDev.

The issue is, some completions/tooltip functions may relay on scopes which makes a syntax definition required. I could start writing one based on default JSON package if no one else started to work on it?

see: https://github.com/deathaxe/EasySettings

[FichteFoll]

I haven't done any work in this direction yet. What is most important right now, as you mentioned, is writing new syntaxes with proper scope names. I won't have much time next week either, but intend to continue with syntax definitions for other resource files. Settings are probably up next.

If you would like to take a look, definitely check out the keybindings definition, which is currently the only rewritten JSON-based definition.
If you would rather spend time on completions, that's perfectly fine too, because I won't be working on that soon-is.

[FichteFoll]

Added in #113 and futher adjusted with #115, #117 and individual commits.