Sublime Forum

**jps** · October 13, 2017, 6:37am

Dev Build 3149 is out now at https://www.sublimetext.com/3dev

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:

{
    "defaults":
    {
        "caret": "blue",
        "invisibles": "#ff0000",
    },

    "rules":
    [
        {
            "scope": "comment",
            "foreground": "hsla(90,90%,70%,1.0)",
            "selection_foreground": "pink",
        },
    ]
}

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":
    {
        "foo": "hsl(20, 50%, 50%)"
    },

    "rules":
    [
        {
            "scope": "string",
            "foreground": "var(foo)",
        },
    ]
}

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.

**jps** · October 13, 2017, 7:06am

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.

**kingkeith** · October 13, 2017, 7:20am

this is awesome! thanks @jps!

**devcarlos** · October 13, 2017, 7:26am

@jps Are we going to get the ability to add a secondary font for ligatures only?

we love ligatures but not everyone is a fan of Fira Code so having the ability to use our favourite fonts while still being able to use ligatures would be fantastic.

**jps** · October 13, 2017, 7:27am

I can’t say at this point

**kingkeith** · October 13, 2017, 7:29am

you could just use something like http://fontforge.github.io/en-US/ to edit your favorite font to add the ligatures from Fira Code.

**aziz** · October 13, 2017, 7:37am

Great job guys,

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.

**devcarlos** · October 13, 2017, 7:51am

How would I go about doing that? i’m installing it now but don’t have a clue where to start.

**ihodev** · October 13, 2017, 7:56am

The new build and color scheme format is absolutely fantastic Thanks a lot for your hard work

**aziz** · October 13, 2017, 8:04am

BTW, while the focus is on text-rendering please fix emoji rendering issues as well. Things like this

**Nicolay** · October 13, 2017, 8:09am

May be because polarization is a totally different concept and has nothing to do with the issue?

**lastsecondsave** · October 13, 2017, 9:14am

I have draw_white_space set to selection but Sublime now draws dots from the beginning of selection to the the beginning of the next word:

**jps** · October 13, 2017, 9:21am

That will be fixed in 3150

**jps** · October 13, 2017, 9:26am

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.

**ono** · October 13, 2017, 9:51am

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.

Filled a bug report at: https://github.com/SublimeTextIssues/Core/issues/2001

Cheers,
– Adam

**prmaple** · October 13, 2017, 11:29am

I just want to stop for a second and chuckle.

**gerry** · October 13, 2017, 12:46pm

style_for_scope addition is great. There is an issue (Ubuntu, tested against MonokaiFree color scheme):

The background is always white #ffffff.

{
 'source_file': 'Packages/MonokaiFree/MonokaiFree.tmTheme', 
'selected_foreground': '#272822', 
'foreground': '#66d9ef', 
'source_column': -1, 
'bold': False, 
'source_line': -1, 
'italic': False,
'background': '#ffffff'}

**facelessuser** · October 13, 2017, 1:59pm

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.

**addons_zz** · October 13, 2017, 2:08pm

Thanks it is fixed:

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?

Build 4147

Build 3148 and 3149

**facelessuser** · October 13, 2017, 2:14pm

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…