Sublime Forum

.sublime-color-scheme and region.colorish

#1

This is certainly one of the issues.

TBH I often don’t know how to get the styles I want.

The first selection is a yellowish region, but you can’t color the fg. The second is closer to what I want using a scoped region self.view.add_regions('vi_search', regs, 'string.search.occurrence', '', sublime.DRAW_NO_OUTLINE)

<dict><key>scope</key><string>region.yellowish</string><key>settings</key><dict>
<key>foreground</key><string>#272822</string>
<key>background</key><string>#e6db74</string></dict></dict>

<dict><key>scope</key><string>string.search.occurrence</string><key>settings</key><dict>
<key>foreground</key><string>#272822</string>
<key>background</key><string>#e6db74</string></dict></dict>

The -ish region highlight looks sharper because the fg #272822 is the color of the outline so it blends with the background. In a region scope the fg color is the text, but you can’t have a fill and an outline and color all three i.e. fg, bg, outline. Unless you can and I don’t know how.

I also may not want to style all region-ish’s the same for all features. I’m assuming a color scheme can still target specific plugin region-ish scopes, or no?

For example, In my color scheme I target GitGutter specifically to add some transparency to lighten those colors specifically for those plugin feature styles, but I don’t want transparency in the less specific markup.changed scope:

<dict><key>scope</key><string>markup.changed.git_gutter</string>                        
    <key>settings</key><dict>
        <key>foreground</key><string>#fd971fa6</string></dict></dict>
        
<dict><key>scope</key><string>markup.changed</string>                                   
    <key>settings</key><dict>
        <key>foreground</key><string>#fd971f</string></dict></dict>

Suppose GitGutter were to use a region.orangeish instead of markup.changed, I assume it can also add it’s own scope so that I can target it specifically? For example maybe it adds region.orangish.git_gutter. So now by default it’s orangish, but I can also target it specifically:

<dict><key>scope</key><string>region.orangeish.git_gutter</string>                        
    <key>settings</key><dict>
        <key>foreground</key><string>#fd971fa6</string></dict></dict>

Am I understanding that correctly?

:slight_smile: I know @deathaxe is probably going to tell me that scope is deprecated.

1 Like
#2

You might want to fix the title since it has nothing to do with the contents.

2 Likes
#3

This post was moved? The post has lost context. I came to follow up with having played around with the api but now I don’t know where to start.

0 Likes
#4

Moving the post here almost put me off posting this. It lost too much context.

/cc @wbond

I think I didn’t understand the region.*ish api’s because when they were introduced they had a lot of bugs so I didn’t know what they were trying to do. I think I understand now. And despite a few remaining bugs and some possible improvements, they solve the issue I was trying to solve by suggesting a Default.sublime-color-scheme. I do want to propose a recommended standard for how plugin authors use the API.

Unable to set foreground bug

Unable to set fg when using a regionish with no outline.

self.view.add_regions('vi_search', regs, 'region.yellowish', '', sublime.DRAW_NO_OUTLINE)

<dict><key>scope</key>
<string>region.yellowish</string>
<key>settings</key><dict>
    <key>background</key><string>#ff0000</string>
    <key>foreground</key><string>#0000ff</string>
</dict></dict>

Whereas when you use a custom scope you can set the fg:

self.view.add_regions('vi_search', regs, 'custom.scope', '', sublime.DRAW_NO_OUTLINE)

<dict><key>scope</key>
<string>custom.scope</string>
<key>settings</key><dict>
    <key>background</key><string>#ff0000</string>
    <key>foreground</key><string>#0000ff</string>
</dict></dict>

Progressively enhancing plugin regionish- styles

The reason I suggested the Default.sublime-color-scheme was to try solve the problem of allowing plugins to set default styles while also allowing color schemes to enhance support specific to the plugin. Despite the few remaining bugs, the region.*ish scopes support this:

self.view.add_regions('vi_search', regs, 
                      'region.yellowish neovintageous', '', sublime.DRAW_NO_OUTLINE)

<dict><key>scope</key>
<string>region.yellowish</string>
<key>settings</key><dict>
    <key>background</key><string>#ff0000</string>
    <key>foreground</key><string>#0000ff</string>
</dict></dict>

<dict><key>scope</key>
<string>region.yellowish neovintageous</string>
<key>settings</key><dict>
    <key>background</key><string>#000000</string>
    <key>foreground</key><string>#ffffff</string>
</dict></dict>

By adding the plugin “namespace” to the end of the scope it does three things:

  1. It will default to use the region.yellowish chosen by ST.
  2. The color scheme can style region.yellowish directly (if it wants to).
  3. The color scheme can style the plugin specifically (in the example above the neovintageous).

To this end I want to suggest that ST recommends a standard way of how plugins add their “namespace” scopes onto region.*ish scopes. Plugins will do it. There’s no avoiding that, it’s just a question of how they do it, and it would be better if plugins were consistent about it. Nobody wants to see plugins all doing it differently like this:

region.yellowish pluginx
pluginy region.yellowish
region.yellowish.pluginz

A standard approach:

Let’s call a plugin namespace the lowercased underscored name of the plugin e.g. “Fizz Buzz” becomes fizz_buzz, “FizzBuzz” becomes fizzbuzz, etc.

The recommended standard could be something like: a plugin should add, at minimum, a namespaced scope, at the end of the region.*ish scope (I don’t know if it’s better to put it at the end or the beginning or append it to the scope, but for now let’s say the end).

Then this means the FizzBuzz plugin would add (oppose to any other variation):

region.redish fizzbuzz

Plugins can add more specificity if they like too:

region.greenish fizzbuzz.valid
region.redish fizzbuzz.message.error
region.orangeish fizzbuzz.message.warning

If plugins are consistent, then if you know a plugin is targeting region.yellowish and you want to style it specifically. Assuming they’ve followed the recommended standard and the plugin name is, say “Batman Begins”, then you already know how to target at least the minimum namespaced style:

region.yellowish batman_begins

Some examples:

region.orangeish sublimelinter 
region.redish sublimelinter 
region.yellowish neovintageous

More specificity:

region.orangeish sublimelinter.warning
region.redish sublimelinter.error
region.blueish neovintageous.search
region.yellowish neovintageous.search.occurrence

And so on…

2 Likes
#5

This seems like it may be a bug. Perhaps Jon restricted the region. scopes to not be able to affect the foreground color – I am not sure.

This seems like a potentially reasonable thing to do. I would probably err on the side of region.redish.plugin so it wasn’t possible to override a bunch of colors accidentally with a selector of region plugin.

This seems to fit in with the idea of plugins adding ids to the HTML they construct for the sake of color schemes. We probably need some docs around best-practices related to plugin authors providing tools so people can easily theme the output of their plugins.

1 Like
#6

I thought about this. I wondered if that could cause problems in the future e.g. if ST extended the region.colorish scopes, might it cause backwards compatibility issues.

For example, let’s say ST did extend those scopes for other features, how would plugins handle it:

region.redish
region.redish.feature

In order to over override you would need:

region.redish.plugin
region.redish.feature.plugin

This was one of the reasons I mentioned that I didn’t know if it was better to prefix or postfix the plugin namespace:

plugin region.redish

vs

region.redish plugin
1 Like
Dev Build 3154