Sublime Forum

**gerry** · November 1, 2017, 7:02pm

Adding support for a Default.sublime-color-scheme would solve many plugin color scheme issues.

One of the issues with plugins and color schemes is that plugins sometimes need to add default basic styles for the plugin features to work out-of-the-box.

For example, SublimeLinter (SL) configures a plain red color for linting errors by generating a new color scheme based on the original, with the default styles injected into it. It only does this if the color scheme doesn’t already support SL.

Ideally:

Plugins could add default styles so that it works out-of-the-box.
Color schemes could progressively enhance support for plugins.

Having a Default.sublime-color-scheme merged before the selected color scheme file is loaded, could potential solve some of the issues above. It’s easiest to illustrate by example (the scopes names I’m using are unimportant for the example):

Packages/GitGutter/Default.sublime-color-scheme

{
    "rules":
    [
        {
            "scope": "gitgutter.added",
            "foreground": "green"
        }
    ]
}

Packages/SublimeLinter/Default.sublime-color-scheme

{
    "rules":
    [
        {
            "scope": "sublimelinter.error",
            "foreground": "red"
        }
    ]
}

Whatever color scheme is selected now has default styles for both GitGutter and SublimeLinter.

Let’s suppose the color scheme “Marvin” wants to enhance support for the plugins:

Packages/Marvin/Marvin.sublime-color-scheme

{
    "rules":
    [
        {
            "scope": "gitgutter.added",
            "foreground": "lightgreen"
        },
        {
            "scope": "sublimelinter.error",
            "foreground": "lightred"
        }
    ]
}

This will mean plugins can provide defaults and colors schemes can enhance support.

**deathaxe** · November 1, 2017, 7:01pm

If the PHP syntax uses the default built-in CSS syntax it is quite normal an error to be risen, if you forbid it to be loaded. This is no issue. PHP is just not designed to work with custom CSS3 syntax. Importing a syntax is always a static thing.

**ngppgn** · November 1, 2017, 7:11pm

While doing further tests, I created a very small syntax to test the embed capabilities to handle nested structures. This syntax should work like this:
you can type A, then you can type either a or (B, then you can type either b or A, then…) -everything else is illegal- so you should be able to write balanced structures like ABAaba, but ABB should be illegal. Instead, the program will CTD when you try to type ABB.

https://pastebin.com/jqcYEyJr

**wbond** · November 1, 2017, 7:20pm

Not from what I read.

  main:
    - match: '^()(a)$' #matches a line consisting only in an "a"
      captures:
        1: conditions.character
        2: conditions.character.scope
      embed: conditions #allows an "a" preceded by at most 1 more tab than the previous line
      escape: '^(?!\1\t)a$' #this should escape if more 1 more tab than the previous line is used
    - match: '.*+' #everything else is disallowed
      scope: invalid.illegal

Capture group 1 will always be blank because you created a pattern with an empty capture group. So the escape will trigger if the line starts with an a that is not a \t. The escape you have is functionally the same as writing ^a$.

Also, Sublime Text’s custom regex engine is not a backtracking engine, so you don’t need to use possessive quantifiers. In fact, using a possessive quantifier triggers use of the slower Oniguruma engine, which will make your syntax take longer to highlight your code.

**wbond** · November 1, 2017, 7:27pm

Since build 3148, SL should add such a region with the scope region.redish and the closest color in the color scheme to red will be used. This way, SL will use a color that fits with the color scheme. The automatically supported scope names are listed in the changelog for build 3148.

These colors are the exact same names/colors as the automatic variables in minihtml.

**ngppgn** · November 1, 2017, 7:40pm

I’m not sure if I’m understanding you on your first point.
The idea is that the first line is “a”, the second then can be either “a” or " a", that’s the pur. Is this not correct then? What would be then the correct way to express that.

Regarding the engine not being a backtracking one, where can I read on how does it behave, then? Does it mean that all quantifiers behave as possessive by default?

**ThomSmith** · November 1, 2017, 7:44pm

Quantifiers are all non-possessive. However, matching should always occur in linear time, unlike backtracking engines that may have exponential worst-case performance. Because possessive quantifiers are primarily used to avoid worst-case performance in backtracking engines, they are not needed in Sublime’s engine, so they were omitted to simplify implementation.

**gerry** · November 1, 2017, 8:03pm

I don’t think that works too well. When I remove the sublime linter color definitions from MonokaiFree I just get white icons instead of orange.

**wbond** · November 1, 2017, 8:10pm

If you run these in the console do you get a colorized gutter icon on line 1?

view.add_regions("test", [sublime.Region(0, 1)], "region.redish", "bookmark")
view.add_regions("test", [sublime.Region(0, 1)], "region.orangish", "bookmark")
view.add_regions("test", [sublime.Region(0, 1)], "region.yellowish", "bookmark")
view.add_regions("test", [sublime.Region(0, 1)], "region.greenish", "bookmark")
view.add_regions("test", [sublime.Region(0, 1)], "region.bluish", "bookmark")
view.add_regions("test", [sublime.Region(0, 1)], "region.purplish", "bookmark")
view.add_regions("test", [sublime.Region(0, 1)], "region.pinkish", "bookmark")

**deathaxe** · November 1, 2017, 8:11pm

What @wbond want’s to say is SublimeLinter should be updated to use current standard scope names instead of his current ones which don’t follow any current scope naming convention.

There was also a proposal to use markup.error or markup.warning as a common scope for such things.

**wbond** · November 1, 2017, 8:12pm

Yes, SL would ideally be updated to use the color-based region names for any build 3148 or newer.

**bantya** · November 1, 2017, 8:29pm

Yes, I too am getting something like:

**deathaxe** · November 1, 2017, 8:38pm

I played around with the new embed command and I am curious about one thing.

The following example shows the modified Git Log.sublime-syntax. The escape should be triggered if commit was found at the beginning of a line. I therefore want to use the back reference of the match’s first capture. Do I miss something or why does it work only with \2 being used as escape value? I’d expect \1 instead as (^commit) is the first capture in match.

Example:

%YAML 1.2
---
name: Git Log
file_extensions:
  - gitlog   # no real extention but why not?
first_line_match: commit\s+\h{7,}
scope: text.git.log

contexts:
  prototype:
    - include: Git Common.sublime-syntax#comments-line

  main:
    # 1st header line
    # commit d9d9fb804f5d61c13ba2f8746af33a9f3c609075
    - match: (^commit)\s+(\h{7,})\s*\n
      scope: meta.header.git.commit markup.raw.block.git.log
      captures:
        1: keyword.other.commit.git.log
        2: constant.numeric.hex.hash.git.log
      embed: commit-header
      escape: \2

  commit-header:
    # All header attributes are mappings of `key: value` format.
    # For simplicity we do not want to distinguish the entries.
    # Author: first lastname <mail@domain.com>
    # Date:   Wed Sep 13 22:42:14 2017 +0200
    - match: ^(\w+)\s*(:)\s*
      captures:
        1: keyword.other.header.git.log
        2: punctuation.separator.mapping.pair.git.log
      push:
        - meta_scope: meta.header.git.commit markup.raw.block.git.log
        - meta_content_scope: string.unquoted.log
        - match: \n
          pop: true
        - include: Git Common.sublime-syntax#email
    - include: Git Commit.sublime-syntax

Possibly found my issue:

The escape is not applied to the - include: Git Commit.sublime-syntax statement.

**gerry** · November 1, 2017, 8:50pm

I see what you what you mean.

This might solve some use cases, but it doesn’t solve the wider issue of plugins needing to providing default styles. For example I was developing a syntax recently for readonly views and wanted to “conceal” various punctuation marks i.e. color them the same as the background. I had to decide against supporting it because no color scheme supports that and I’d have to go ask them to. ST could support this in the core with a region.conceal, but once again a) that doesn’t help me now, and b) it only solves the specific case.

The ability to provide defaults can also help standardise scopes without hindering the plugin. For example @deathaxe points out common scope proposals. Nobody can use them right now because no color scheme supports them. If plugins can provide defaults then they can start using them and hopefully that would lead to them becoming standard.

**deathaxe** · November 1, 2017, 9:01pm

Despite the fact ST always would effectively need to load 2 color schemes, the Default and the selected one, with possibly a couple or a lot of Default files to merge, you’ll hardly find default colors which look well to each color scheme. The main “default colors” are covered by the “redish”, … colors.

You try to create a (probably nasty) workaround for the issue of some color schemes not being maintained any longer.

The goal should not be to let each plugin define its own scopes and colors. I am concerned this to result in no-one making up their mind about scoping and just create plugin-specific scope names and colors, resulting in work getting harder for color scheme authors to catch all the divergent plugin’s scopes and colors.

This is exactly what was tried to overcome by the recent work on default syntaxes. Avoid language/plugin unique scope names. You suggest to even add unique plugin colors.

I understand the reason for the request, but am not sure whether it helps keeping things together in the long term.

**ngppgn** · November 1, 2017, 9:02pm

So, any other feature I should avoid besides possessive and lazy quantifiers to ensure the fast engine is being used? Is there any way to configure sublime to always use the fast engine and throw an error if a feature not supported by it is used?

**wbond** · November 1, 2017, 9:03pm

No, but in the Syntax Tests build system there is a build variant that allows you to test for regex compatibility.

**ThomSmith** · November 1, 2017, 9:06pm

To avoid the slow engine, you should avoid:

Backreferences.
Atomic groups.
Possessive quantifiers.
Lookbehind
Subexpression calls.

I think that all other Oniguruma features are supported.

**wbond** · November 1, 2017, 9:13pm

Well, I think we identified a popular plugin that was doing something sub-optimal for the user and provided a way forward that allows things to look nice, and not resort to hacks. It may not solve every situation, but I personally would be hesitant to encourage one-off scope and color scheme names and default “styles”. I think we need to try and find a way so users can control the color of their editor, and make a way that plugin authors can respect those colors. If we have other situations we need to solve, we can look at them and brainstorm about what the best path forward is to solve them.

Some feature requests we are going to say, “sorry, that doesn’t seem like a good fit for Sublime Text to support.” But I think discussing ideas and trying to find good paths forward that don’t lead us into a corner needs to be the way we address things. And then we have to prioritize the ideas we do come up with. I mean, one idea is that we could expand the pre-created region. scope names to include foreground, background and accent.

**wbond** · November 1, 2017, 9:14pm

I look into this and see if I have an off-by-one error in there somewhere.

Dev Build 3153