Dev Build 3153

[wbond]

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 look into this and see if I have an off-by-one error in there somewhere.

[ngppgn]

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

[ThomSmith]

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.

[braver]

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

[ngppgn]

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

[ihodev]

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:

Dev Build 3148

Dev Build 3148 is out now at https://www.sublimetext.com/3dev 3148 contains the second part of ligature support, with selection drawing redone so ligatures don't get mucked up by the selection. In the old system, rendering went like this: draw the background, draw the text, draw the selection box, draw the text in the selection box. In the new system, rendering goes like this: draw the background, draw the selection box, draw the text. Doing only a single pass over the text allows ligatu…

[ngppgn]

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.

[kingkeith]

I still think there’s some weirdness at work here

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.

[ngppgn]

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.

[ngppgn]

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?

[hkdobrev]

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?

[ThomSmith]

This coupled with the fact that the syntax higlighting for the sublime-syntax format doesnt recognise values of embed:

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

[deathaxe]

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.

[deathaxe]

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.

[Markus_Gritsch]

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

[jps]

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

[kingkeith]

please can escape be updated to support variables?

[darby3]

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…

[kingkeith]

you can report it at https://github.com/y0ssar1an/CSS3/issues

[wbond]

When the core CSS package is disabled and the CSS3 package is enabled instead, I get this error:

After the update I find an error like this with HTML syntax.

Yes, I too am getting something like:

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?

I got the same error, and the result is syntax highlighting in my PHP files is gone.

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.