The first change in 3149 is selectionForeground coming back better than ever: it can now be specified on a per-rule basis, so you can now have both a high-contrast selection, and still have syntax highlighting.

An a minimal example, you may want to change your selection color to something bright, and then edit all the rules with colors close to the selection color, changing them to use a different foreground color when selected.

Doing this via editing plist XML isn't much fun, so 3149 also comes with a new color scheme format, .sublime-color-scheme. This mostly keeps the same schema, but has a JSON surface syntax, and allows override files, similar to most of the other Sublime Text formats. Here's a short example:

If you save this as User/Monokai.sublime-color-scheme (.sublime-color-scheme files can override rules in both other .sublime-color-scheme files, and .tmTheme files), then you'll get a blue caret, red whitespace, and light green comments that turn pink when selected.

You may have noticed in the above example that you can also use CSS syntax to specify colors: this includes hsl(), rgb() and var().

Variables are another item added in the .sublime-color-scheme format. An example:

Variables can also be overridden in .sublime-color-scheme files, so they provide a nice way to let users customise your color schemes.

Note that in sublime-color-scheme files, keys should be specified via cool_hacker_case, rather than camelCase.

Just to be clear: sublime-color-scheme format is subject to change, and nothing is finalised yet. The default color schemes have not been converted to this format, but they likely will in a future build.

On the topic of making color schemes easier to edit, there are a few plugins that manipulate them. With the format getting more complex, Sublime Text now provides a bit of assistance: there's a new API call, view.style_for_scope(str) that will give you information about the style used for a specific scope, as well as where that information comes from. Note that the source line and column information is only filled in if it comes from a .sublime-color-scheme file, and not a .tmTheme file.

Expanding on the selection_foreground logic: if it's entered at the top level, then it'll override everything. If it's entered for just a single rule, then it applies to that rule only.

If you want to specify the selection foreground for otherwise unstyled text, but still keep the other foreground colors unchanged, then you'll want to set implicit_selection_foreground to "true" at the top-level. This will give every rule an implicit selection_foreground that's equal to its foreground.

The new color-scheme format with variables is really promising. I'm waiting for the official documentation and hopefully a tool to convert the old tmTheme to the new format (should be easy to write a small script myself)

Is any technical reason you choose JSON and not YAML? I thought YAML would have been cleaner and more consistent with the syntax definition files.

Is any technical reason you choose JSON and not YAML? I thought YAML would have been cleaner and more consistent with the syntax definition files.

YAML is a complex format, and most people won't understand the subtleties of the syntax. While it looks nice, I don't think it's appropriate for file formats that will be casually edited, such as preferences and color schemes.

YAML is used for syntax definitions because double escaping all the regexes in JSON is impractical, and writing a syntax definition is fairly involved in any case.

First of all thank you so much for invisibles, it really appreciate the change and the pace of the recent ST development.

Now some observation (regression), it seems starting 3147 Sublime is rendering text on Windows much different that it used to be and much different than other apps e.g. Visual Studio 2017 (that is also using direct-write AFAIK) or Chrome. It looks like there is no more font hinting - text appears smeared and much bolder than it used to be. IMHO this is regression and may be related to my 125% DPI scaling setting.

Yeah, I really like style_for_scope, but it would be nice if it always returned the actual background for the scope. It seems to not tell you if the background is the global background, and instead gives you a meaningless value.

One other thing that would be nice is if you could somehow acquire general global values without parsing the scheme. Like if I wanted to acquire the gutter color, or the general selection color. Or really anything like that. With the introduction of variables etc., simply parsing a color scheme and acquiring the global colors sounds that much more difficult, and having an easy way to acquire that would be very helpful.

Now there is another problem which started with build 3148. The definitions show up are taking longer to show and are being rendered in two phases, it is quite annoying and now takes longer to see the definitions. Can this be restored?

I guess we might be able to get away with loading a color scheme with load_settings and they may merge all overrides. Then you could track changes like you can with any settings...it may be possible to get all of this reliably already... with some work. If you didn't want overrides, you could just parse the file directly...