Sublime Forum

Dev Build 3153


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.



Yes, after remove CSS3 package and enable CSS native package the problem is solved.



Question: if we wmbed: X and then within X we set Y, will X’s escape regex still be checked or not?



If you pop out of an embedded context (via pop or set) it should discard the escape pattern and continue on as the action you specified requested.

1 Like


There shouldn’t be. I will have to dig into it some.

You will probably want your escape to be ^(?=\1) so that it is anchored to the beginning of the line. The backreferences will capture literal text, but not assertions like ^.



Further question about embed: I know we can capture a group in the match that embeds and abckreference to it in the escape regex, but can we also bacreference to said capture group in the regexes defined within the embedded context? Because that would be really handy.



I’m not sure if this is related to this report:

but I’ve noticed that ST’s hashed syntax highlighting treats each “token” as a separate entity, even when scoped the same (with the same match pattern even) as the adjacent text. i.e. a match pattern for . instead of .+. This can be most clearly seen with the example .sublime-color-scheme you provided with the find panel, typing a literal like testing123:

on a related note, it would be great if plugins that query for scope information could find out the extent of a scope that was applied from one match pattern, for example to distinguish that .. in regex syntax is actually two tokens of . and not one token of .., or that \s\w is one token of \s and one of \w, and not one of \s\w which is what view.find_by_selector('keyword.control.character-class.regexp') or view.extract_scope would have you believe - I guess a separate API would be needed for this for backwards compatibility reasons.



No, unfortunately that would require dynamic regex patterns for a context, which would have a drastic impact on performance.



so colorocoder is core now. well we had a good run. just sad i didnt get a shoutout