Dev Build 3153

[gerry]

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.

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

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]

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]

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]

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?

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

[ThomSmith]

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]

This might solve some use cases, but it doesn’t solve the wider issue of plugins needing to providing default styles.

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]

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.