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
Clean up settings #140
Clean up settings #140
Conversation
- separate settings into its own class - apart from `trailing_spaces_highlight_color` which has special handling, get all options directly from settings so that they are always up to date with user preferences. Previously settings were only read on init.
I suggest using https://sublimetext.github.io/sublime_lib/#sublime_lib.NamedSettingsDict and a dict with defaults with collections.ChainMap. |
Actually, I also strongly suggest dropping the redundant |
Great suggestion about using sublime lib. |
Would be trivial, imo. Just wrap the settings dict it in a SettingsDict subclass that prefixes all keys with |
Also remove `trailing_spaces_` prefixes from settings. Settings with prefixes are still respected for backwards compatibility.
That extra layer actually needed to be first in the chain. |
Hi! TLDR: I like the fix of (re)loading settings, I don't like removing the I ended up here because I would want to be able to change trimming settings between syntaxes and projects etc. and this doesn't seem possible yet. It doesn't seem that this pull request addresses that issue, but if you were to accept this pull request, it would become unclear which setting to use: normally, Sublime's philosophy is to use one settings key that you can use anywhere (project, syntax or user settings), but leaving off the What do you (plural) think? |
Some (references for) inspiration:
|
This package doesn't read from computed settings currently. Maybe it should, but the feature doesn't exist at the moment. All the settings currently being read are automatically namespaced through the file they are defined in. If reading computed settings was to be added, however, I personally (and other plugin authors as well) favor the dotted approach of SublimeLinter, as that clearly separates the namespace from the setting's name and does not suffer from the problem of subsequent overrides that a nested mapping key would (e.g. overriding only one key in a syntax-specific settings file and another in the project settings, where the override applied latest would shadow any earlier override). |
I am up for dotted approach too. |
trailing_spaces_highlight_color
which has special handling,get all options directly from settings so that they are always up to
date with user preferences. Previously settings were only read on init.