Sublime Forum

Dev Build 3153


Bthank you very much. I hope that ysing backreferences to groups in the match inside escape patterns is an exception then.



I very much doubt that it is; those expressions will probably use the slow engine. When used sparingly, the performance cost for slow expressions should hopefully be low.



FYI work is ongoing to move Sublime Linter to use the region.color scopes etc. It’ll be sweet!



Forgive my ignorance, but what are region.color? A search in the forum only yields your post



The regions color system has never been that great, to help alleviate the above changes, I’ve also added support for some automatically generated scopes (region.redish, region.bluish, etc) that are based on the color scheme, but should have enough contrast such that the text can be seen. Color scheme files can also explicitly create selectors against these scopes to better control the colors used.

Details here:



Sorry to keep bugging you, but I still think there’s some weirdness at work here.

I’ve created a simplified version of the syntax above. Now the rules are:
-main contex: allow a line consisting only of an “a” at the start and nothing else, embed second escaping when a line doesn’t start with a space,. Everything else is illegal.
-second context: allow a line starting with a “_” following by anything; everything else is illegal.
Here is the syntax:

And here the testing text:
a this line should be marked illegal, but isn't this line is correctly considered illegal.

It looks like the line where the escape is matched is skipped completely, regardless of wether the actual scape pattern consumes any character.



I think the weirdness is coming from your use of .*+ instead of .+, fix it up and the scopes become illegal as expected. You are saying “match any number of non-newline characters possessively”, so if 0 chars match, and it is possessive, then it is the end of the match.

1 Like


That is weird to my understanding, but you are correct here. Shouldn’t have been using possessive quantification there anyway, it’s just a bad habit, but I don’t understand why does that happen. Possessive quanfitiers should eagerly match as many as possible, so a .*+ should match up to the end of the line, if I’m understanding possessiveness correctly.



Further error: in the syntax linked in the quoted post, if you remove the cloing bracket in line 12 and save, instead of getting an error report about a yaml syntax error, the editor will auto-close. When you try to open the editor again, it will auto-close immediately. This will subsist until you open the file with another editor and fix the missing bracket.

This coupled with the fact that the syntax higlighting for the sublime-syntax format doesnt recognise values of embed: as regexes but instead as normal strings makes it very annoying to have any error in your syntax.

Should I open a separate thread in Bug Reports for this?



So you are saying both the CSS and the CSS3 packages should be enabled with this build if I want to use PHP and CSS3?



A PR has been submitted to add embed and escape to the PackageDev .sublime-syntax highlighting.



No, I say the PHP syntax is not designed to work with the custom CSS3 syntax. It will always use the built-in CSS syntax. You’d need to copy the default PHP.sublime-syntax and replace the CSS include statement by CSS3 or rename your CSS3.sublime-syntax to CSS.sublime-syntax after disabling the default one.



I think, I was confusing myself by another issue or limitation, yesterday. I tested the code against my syntax_test_git_log file from

After some further investigation it turned out that escape doesn’t work at all because of the - include: Git Commit.sublime-syntax statement, no matter which escape pattern I use. If I comment out this include statement the escape: \1 works properly.

Are there some limitations with the escape in combination with including external syntaxes in the way I used it?

I added some files for investigation to

If you copy the “Git Files” to your Packages folder and follow the instructions in the commit message, you should see what I mean.



When using “Hashed Syntax Highlighting”, shouldn’t the yellow marked “maintime” variable always have the same color? Also the purple marked “lastlooptime” variable:



It should - I’ll fix that for the next build

1 Like


please can escape be updated to support variables? :slight_smile:

1 Like


I got the same error, and the result is syntax highlighting in my PHP files is gone. It doesn’t feel like I should have to manually modify packages to make something work that was working fine one build ago, but I’m also not entirely sure where to report this as an issue…



you can report it at



The issue is that you have disabled the CSS package, per the instructions of the CSS3 author. Unfortunately, disabling the CSS package breaks the HTML syntax. The style attributes need to reference a specific context of the CSS syntax. When you disable the CSS package, it makes that context unavailable. With this build we moved the CSS and JavaScript code in the HTML syntax use the new embed syntax. When it tries to resolve the embedded context, it isn’t able to find it.

Honestly, if the CSS3 package is going to tells users to disable the CSS syntax, it will likely need to include it’s own HTML syntax that embeds CSS3 instead of CSS. Alternatively, if the CSS3 syntax can create a context named rule-list-body and I will make sure that the HTML syntax references scope:source.css#rule-list-body for the next build.

Edit: the HTML syntax now references CSS via scope name, so all the CSS3 author needs to do is create a context named rule-list-body that will properly highlight the contexts of a style="" attribute.


Color theme aren't working

Yes, I will get that added.