Bthank you very much. I hope that ysing backreferences to groups in the match inside escape patterns is an exception then.
Dev Build 3153
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: https://pastebin.com/6Ds2Xzp2
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.
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 https://github.com/sublimehq/Packages/pull/1126
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 https://github.com/deathaxe/Packages/commit/ab5e82ce6ebadb5ff35a0b1e530a7bcfd1b783f8
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:
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âŚ
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