-
-
Notifications
You must be signed in to change notification settings - Fork 13
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
New .sublime-color-scheme list support #46
Comments
General thoughts as I prepare to approach this:
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. |
Sublime API seems to exclude rules with gradients in them with calculating |
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 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. |
Turns out while Sublime supports specifying tmLanguage are loaded first and then So when specifying a Merge logic will be updated to accomadate this realization. |
* Backwards compatible gradient support Ref #46 * Adjustments to parse logic - Ensure user overrides are always merged last - If colors are not string, don't fail, just assign none * Fix doc errors * Rework merge logic as it was wrong.
I really like the new changes coming in, but ugh, so much work.
The text was updated successfully, but these errors were encountered: