BracketHighlighter2 BETA Branch

[facelessuser]

[quote=“iamntz”]Thanks! Works… partially

because it also match if(){} expressions (and it shouldn’t)

what i came up is this pattern:

            "open": "^\\s*(if|foreach|while).*:$",
            "close": "^\\s*(endif|endforeach|endwhile;$)"

Thing is… while in regexbuddy works just fine, in editor it doesn’t. Most likely i do some escaping wrong. Any idea which is that? Thanks!

Btw, i noticed that if there is an error somewhere in the config file, the plugin stop to works until i restart ST. It’s a bug, a feature or a bit of both? [/quote]

I need to think about this. Basically the open regex and close regex occur on separate passes. So for “if():” the open regex gobbles up “(” and “)”, but the close pass finds “)”. So when the brackets get resolved, it can’t pair up “)”, because the open got gobbled up in “if():”.

Basically, the this is a case where the open regex intersects with the close. I need time to think how to resolve this issue.

As for the plugin stopping working on bad settings file? I will have to think about how to gracefully handle that as well.

[facelessuser]

@iamntz
I need to change the algorithm to do opening and closing in one pass. I have it working on my computer, but I need to stream line it. I guess it will actually be a little quicker this way.

I will let you know when it is done, maybe sometime in the next couple of days.

[iamntz]

I will let you know when it is done, maybe sometime in the next couple of days.

I survived about 4-5 years without that highlight, I guess i’ll handle it few more days!

Thanks!

[sublimator]

Dunno what you doing exactly but look ahead / behinds?

[facelessuser]

Dunno what you doing exactly but look ahead / behinds?

Yes lookaheads will help him because they won’t capture, and can allow things like “()” to be used twice, but regardless it is probably better to do find opening and closing in one shot to limit confusion.

With the current implementation of processing opening and closing separately, it is easy for a user to not really understand what is happening. They expect if they capture something in opening, it shouldn’t be captured in closing.

I should have a fix posted in a couple of minutes. I will also post a solution for your problem @imantz using lookaheads.

[facelessuser]

Fix is in on the alpha branch.

Based on your earlier config, try this (I am not entirely sure what you are looking for, so I have just adapted your earlier post):

[pre=#2D2D2D] {
“name”: “php_keywords”,
“open”: “^\s*\b(if|foreach|while)\b(?=.:$)",
“close”: "^\s\b(endif\b|endforeach\b|endwhile(?=;$))”,
“icon”: “dot”,
“color”: “brackethighlighter.tag”,
“style”: “underline”,
“language_filter”: “whitelist”,
“scope_exclude”: “string”, “comment”],
“language_list”: “HTML”, “HTML 5”, “XML”, “PHP”, “HTML+CFML”, “ColdFusion”, “ColdFusionCFC”],
“plugin_library”: “User.phpkeywords”,
“enabled”: true
},[/pre]

A much simplier phpkeywords.py now:
[pre=#2D2D2D]def compare(name, first, second, bfr):
return “end” + bfrfirst.begin:first.end].lower() == bfrsecond.begin:second.end].lower()[/pre]

Just to be safe, restart ST2 when you update BH to the latest commit.

Edit: The regex is a little sloppy and can be cleaned up, but it is fine for a starting point.

[vitaLee]

Yes, lookaheads might help but the problem is they won’t capture.
The consequence of that will be if later you’d like to take advantage of other features like “select between brackets”, “remove brackets”, “go to opening/closing bracket” you’ll have problems with leftovers that were’t captured, etc…

[facelessuser]

[quote=“vitaLee”]Yes, lookaheads might help but the problem is they won’t capture.
The consequence of that will be if later you’d like to take advantage of other features like “select between brackets”, “remove brackets”, “go to opening/closing bracket” you’ll have problems with leftovers that were’t captured, etc…[/quote]

Yes, there will be a tradeoff. If you use lookaheads, “select between brackets” will grab the “()” brackets which may not be desirable. If you don’t use the lookaheads. BH will not match the “()”. The good news is I fixed the issue where BH would find the closing bracket twice, now it will just ignore it.

The tradeoff is a limitation of BH. The needed complexity of recursive bracket matching to overcome this I don’t think is worth it, but it could be a possibility in the future if it is really required, but I will push back on it for now.

[facelessuser]

oh @iamntz, you can use the old PHP configuration if you want to capture the round brackets. BH supports that now. I just posted the other because @castles_made_of_sand mentioned the lookaheads. It is a good example of how you can workaround certain scenarios.

[iamntz]

You rock! Works beautiful. Thanks a lot!

[facelessuser]

I admit, I am a bit surprised that that was the first real bug discovered; I expected more .

As for a bad settings file causing BH to stop, I will try and put in a catch to keep it from exiting the script. I will see if I can keep the BH thread functional. Worse case scenario, I can add a restart command to start it again.

[facelessuser]

@iamntz
What kind of settings errors were you talking about. Before I approach this, I want to make sure I understand what kind bad settings issues I should be looking into.

[iamntz]

Well, not sure. When i tried different patterns on that if/endif thing i noticed that a bad regex will stop highlight everywhere. The thing is i can’t reproduce it, it’s some kind of Lance Armstrong bug

I’ll let you know if i will figure out.

[facelessuser]

No biggie, just let me know if/when you can pinpoint it.

I haven’t spent much time hardening the plugin against bad settings inputs yet. This is because I haven’t finalized the settings file yet. If/when I separate style stuff from bracket definitions, it will probably change a lot of stuff.

As I get closer to a beta, hopefully a lot of that will get cleared up.

[Eduan]

This is awesome Isaac! I think this is getting to the point where it is no longer alpha.

Just wanted to ask a question though, I haven’t installed this package so don’t know exactly how it works.

But from what I’ve seen in the images, even a single curly bracket ( { ) will put a two brackets image ( {} ) in the left. Is this updated so that it only shows one, meaning the closing one or the opening one, or both if it applies.

[facelessuser]

Picture is worth 1000 words:

[Eduan]

OK I see how that works, could you modify it so that it shows the opening tag, closing tag, or both depending on which one is found? Or would it be too much? Just cause I think it would really make things clearer.

• Eduan

EDIT: I did not read the text, lol. That’s awesome, glad it works, just gotta add the correct icons then?

[facelessuser]

In order to do that I need icons.

currently I have:
icon.png
icon_small.png

To do what you want for a particular bracket I need (brackets that do not want to show open and close could omit the open and close):
icon.png
icon_open.png
icon_close.png
icon_small.png
icon_open_small.png
icon_close_small.png

I am not a fan of making lots of tiny icons and trying to position them just right. But I will make everyone a deal. If someone provides all the icons all lined up nice and with the size variants, I will add the functionality . Deal?

[Eduan]

Deal! So what do you want me to do? Just center them and make them small when the image is small?

[facelessuser]

Deal! So what do you want me to do? Just center them and make them small when the image is small?

Kind of, but not quite.

• Icons are 16X16 regardless if they are big or small.
• The icons need to be white with transparent backgrounds so that when they get masked they are the correct color.
• They need to all be relatively lined up and look appropriate aligned in the gutter. So if the curly icon is centered in the gutter, and the round looks like it is left justified, it is jarring. They all need to roughly be centered/aligned the same.
• Small icons are the same size png as the large, but you have to shrink the actual icon in roughly in the upper left quadrant. If someone made a template that had a layers with guides to optimally place the icons that are big or small, that would help.
• Next you need open and close and normal (both opening and closing) for the icons that make sense. And you need small variants of all three.
• Follow the naming convention shown above.

Icons like “dot” etc, that don’t make sense having opening and closing can omit the open and close variants.

That is it. If you do that, I will add the support. Currently I show show the same icon on closing and opening, and if any bracket cannot be matched, I show the same invalid icon. Do not worry about invalid icons, I am leaving that generic. If you come up with a better invalid, that is great.