A file setting like “src/*.cc” is arguably more specific (and thus more local) than targeting the scope “source.c++”, so it makes sense that the file settings rank higher than scope settings.
Some users also find it natural to target file extensions over scopes, but as TM will store some learned settings with a scope selector, it would previously lead to confusion, when a user was unable to e.g. change tab size for “*.php” (because TM had a learned setting for “source.php”).
This was previously public so that we could write tests for it, but since the test runner is linked with the object files, it can access symbols that has visibility set to hidden.
We generally lookup include/exclude patterns for a folder rather than a file, and here it makes sense to allow the bracketed sections of the property files to target the folder.
Since the sections are not ranked based on how good a match they are, targeting a subfolder, and then a subfolder of this subfolder, does not have which settings take precedence defined.
This is so that a global setting for ‘source.ruby’ takes precedence over a local ‘source’ setting.
A minor downside is that a local properties file cannot use scoped settings outside a scope selector section.
