I’ve been thinking about this ever since the discussions raged about not having per-syntax or per-project settings. The
Config class already has support for two “layers” of settings, defaults and the user’s settings. We just need to extend it to handle a couple more. I wanted to discuss it here first so that people could give me ideas before I tried to implement it.
The layers that I’ve seen suggested in one form or another are the following (in order from highest to lowest precedence):
- Project-specific settings
- Syntax-specific settings
- User settings
- OS defaults
- Editor defaults
Layers #3 and #5 we already have. It was suggested to add #4 and I think it is a good idea. The thing that layers #3-#5 have in common is that they’re not conditional. Layers #1 and #2 change depending on what file or folder we’re talking about. (Though I want to get rid of the idea of syntaxes keying off of file extensions and change to keying off of grammar names … that’s an idea for another time.) So my thinking was that the signature of the configuration methods would change slightly …
class Config get: (keyPath, editor, project) -> # ... snip ...
project weren’t supplied, then everything would work as it does currently (with the added benefit of having OS defaults available) … so no breaking change. If they were supplied, then
Config would add the syntax- and project-specific settings to the setting resolution scheme and get the value.
The reason why I chose the
Editor object rather than the file path is because perhaps the user has set the grammar to something different this session? I think we would want the configuration retrieved to reflect the grammar selected. For similar reasons I chose the
Project object, though this means probably that sub-paths under the project wouldn’t be able to have their own settings that override the project settings.
What does everyone think?