New .sublime-color-scheme list support

[facelessuser]

I really like the new changes coming in, but ugh, so much work.

[facelessuser]

General thoughts as I prepare to approach this:

• So it sounds like this is restricted to foreground in rules, so that is how I will approach it initially unless I discover otherwise.
• Handling the parsing of the list in general should be easy enough, but it kind of messes up the API when returning colors (though I could restrict it to always return the first color).
• I can't think of a reason as far as mdpopups goes where I'd need to interpolate a gradient. If going through Sublime's minihtml, I'm pretty sure Sublime won't be hashing the content of the HTML to determine a color. As far as the existing Jinja2 filters that return the style for a scope, I won't have content context anyways, so returning the first color in the list makes the most sense.
• As far as code highlighting in fences (and other plugins that render code directly, or want the actual color: ExportHtml, ScopeHunter), we can always just request the actual foreground color via the Sublime API when we have a list, or just return the first color (either may be easy enough and may depend on the preference of the plugin, but I need to look how the API is used). Plugins like ThemeTweaker don't care as they just process the colors, so it would process all the colors in the list.

Maybe for backwards compatibility, the first color is always returned by ColorMatcher, then an option in the API can be added to retrieve the gradient color Sublime uses if given a view and point. ColorMatcher can probably return an attribute that mentions the color is a gradient.

At this point, I can't think of a reason to reverse engineer how Sublime lerps the gradient colors. If you want to know what Sublime chose, just use the Sublime API (but we can provide a wrapper). Else just grab something (the first color). The important thing is to keep plugins from breaking with the new format.

[facelessuser]

Sublime API seems to exclude rules with gradients in them with calculating style_for_scope. Maybe this should be an option when guessing colors. Maybe for our purposes we should do the same. For ScopeHunter, it may actually make sense to show the gradient, but maybe not for mdpopups and ExportHtml.

[facelessuser]

So some initial work was completed. ColorMatcher should still return colors just like the Sublime API does as the Sublime API does not return hashed colors as that would require content context, so neither does ColorMatcher. But ColorMatcher will calculate which scopes could use the hash/gradient colors and will return a gradient object and the gradient selector attribute. So people can be aware that this scope would receive gradient colors, and they'd know what scope is responsible for it, and what the gradient stops are. And it is automatically backwards compatible.

If we are evaluating a "selected" color, you shouldn't get a gradient if selected_foreground is defined as from my understanding, only foreground (in rules array) uses gradients, not selected_foreground. I will double check though.

It is possible that Sublime in the future will expose a way to get the color at a specific point, but since that is not possible now, and it would take a ridiculous amount of work to sort of guess how gradients are assigned, we will fall back on normal syntax highlighting, but give the information so that plugins like ScopeHunter can show that a particular scope can receive a gradient color, and what the range of colors is. If someone really wants, they could always pick a color from the gradient and get even closer to Sublime's highlighting, but I imagine me trying to implement the hashed highlighting would never match up exactly right, but I could do something similar (if I ever feel like it) in the future.

[facelessuser]

Turns out while Sublime supports specifying .sublime-color-scheme as Packages/MyPackage/scheme.sublime-color-scheme, the folder path is ignored and the scheme is simply treated as scheme.sublime-color-scheme. So regardless of which instance of scheme.sublime-color-scheme you point to, all are loaded in order alphabetically with User package being an exception and evaluated last.

tmLanguage are loaded first and then .sublime-color-scheme merged on top.

So when specifying a scheme.sublime-color-scheme in preferences, the folder path is not needed as it is ignored.

Merge logic will be updated to accomadate this realization.