BracketHighlighter 2 Moar Bracket Powa!

[facelessuser]

Just to let users of Bracket Highlighter know, I am doing a re-write of the algorithm which is going to change a lot of things. Settings file will be different etc.

The reason is to allow more functionality. The current bracket matching algorithm has been re-written to allow for better things. In the future users will be able to define their own arbitrary “bracket” pairs. They will be able to override key points in the algorithm to assist in whatever bracket comparison or post matching stuff they are trying to do.

It will also do things like highlight a unmatched bracket in a special warning color.

An example showing special ruby highlighting and showing highlighting of unmatched bracket

Example configuration for ruby highlighting:
[pre=#181818] {
“name”: “ruby”,
“icon”: “dot”,
“open”: “\b(?:if|unitl|while|def\s*[a-zA-Z_]+)\b”,
“close”: “\bend\b”,
“sub_groups”: 0,
“color”: “keyword”,
“style”: “underline”,
“scope_exclude”: “string”, “comment”],
“language_filter”: “whitelist”,
“language_list”: “Ruby”],
// “plugin_library”: “bh_user_modules.ruby.ruby”,
“enabled”: true
}[/pre]

I will be looking for testers. If anyone is interested in doing some testing sometime in the next couple of weeks, let me know. If you have any suggestions, now would be the time to chime in.

Though testing might start in a couple of weeks, it may be a while until I finish it completely for release. We will have to see how lazy I am and how much unforeseen issues pop up.

[xeno.by]

Will search_threshold be expanded? Currently I have it at 2000 and making it a 5-number figure brings noticeable slowdowns (I’m sitting at a 2.7Ghz Sandy Bridge i7, so it’s not the CPU that holds highlighting back).

Quite often I need to make sense of compiler AST dumps written like Apply(Select(Ident(“foo”), “bar”), List(Literal(Constant(2)))). The problem is that on dumps of non-trivial sizes, Bracket Highlighter gives up, forcing me to use paren-mode in Emacs (the only reason I’m keeping Emacs around these days). If that could be improved, it’d be lovely.

[facelessuser]

Right now I am using a threshold of 8000. I used to use a threshold of 4000.

I have a i7 3.40 GHz processor at work. At home I run the same settings on my macbook pro.

I have this ridiculous script file at work that is 55,000 lines of code. It seems fine at a threshold of 8000. I haven’t pushed the limits yet. This is all early stage stuff. I haven’t really compared speeds of old vs new. But I imagine it would be faster due to not having to call the ST2 API on every character like the old used to do.

[facelessuser]

Update: Just tried out 10000. Seems to work good here. Mileage may vary; I haven’t tested it much outside of my own computers.

[facelessuser]

Initial tests are showing big noticeable speed improvements for BH2…and I think I can get even more speed out of it. So this is a very good thing. It seems abandoning the original algorithm was the way to go, it is just going to take a while to git this mature enough for release.

[xeno.by]

Initial tests are showing big noticeable speed improvements for BH2…and I think I can get even more speed out of it. So this is a very good thing. It seems abandoning the original algorithm was the way to go, it is just going to take a while to git this mature enough for release.

That sounds very good!

While we’re at it, would it be possible for you to implement something like this, the highlighting of the stuff inside the matching parens (screenshot of parent-mode in emacs):

[facelessuser]

[quote=“xeno.by”]
While we’re at it, would it be possible for you to implement something like this, the highlighting of the stuff inside the matching parens (screenshot of parent-mode in emacs):[/quote]

Kind of, but not in a usable way. See this post for more info: viewtopic.php?f=3&t=5429&p=24041&hilit=brackethighlighter#p24041.

[xeno.by]

Might be useful if easily togglable.

[facelessuser]

Might be useful if easily togglable.

I don’t think that would be a problem. If you could put in a feature request on github, that will help me remember to look into this. Right now I am focusing on some core stuff.

[Rezzie]

Example configuration for ruby highlighting:
[pre=#181818] {
“name”: “ruby”,
“icon”: “dot”,
“open”: “\b(?:if|unitl|while|def\s*[a-zA-Z_]+)\b”,
“close”: “\bend\b”,
“sub_groups”: 0,
“color”: “keyword”,
“style”: “underline”,
“scope_exclude”: “string”, “comment”],
“language_filter”: “whitelist”,
“language_list”: “Ruby”],
// “plugin_library”: “bh_user_modules.ruby.ruby”,
“enabled”: true
}[/pre]

Where do I need to save this to enable Ruby matching?

[facelessuser]

[quote=“Rezzie”]
Where do I need to save this to enable Ruby matching?[/quote]

It only exists on my computer right now . I am trying to find people willing to test when I have a more solid test branch. If you are interested, I will let you know when I have a branch up.

[facelessuser]

BH2 is coming along nice. It can now match the basics like {}, ], (), <>, and tags. You can also define custom pairs. It can find like brackets such as “” or ‘’ if they are part of the same scope. You can also define custom pairs of these as well.

All matches are currently performed when the cursor is between the brackets. The old version would allow you to touch the outside of a bracket with the cursor; this functionality does not currently exist, and probably won’t on initial release (if at all; it would really depend if enough people called for it down the road).

In general, the search time for brackets matching is more flat with a given threshold in the new version. The old way, the bracket match was quick when the brackets were close, and much slower when they were further away. Increase the threshold, and really far brackets were really slow. The new search method is quicker for further away brackets, but it is more flat. Close brackets and far brackets search time is not so so drastic anymore. If you increase the threshold on the new version the whole range slows a little, but comparing a threshold of 4000 between old and new, the new is much faster on average than the old.

I know this might not make since, but in short, on average, BH2 matches brackets faster and it is more configurable for almost any “bracket” pair you want. Basically you will be able to increase your threshold and search further and it still feel like it did on lower thresholds in BH1.

I have also added functionality that will wrap a given selection with any bracket pair you want. You can even configure it to indent etc. So if I had some C code and I wanted to but an #if/#endif switch around it, BH2 would block it off and surround it with the brackets. If I had some Ruby code and wanted to put a if/end conditional around a selection, BH would wrap the selection and indent the content (if defined to do such). You would then have to define the actual condition, but the if/end would be wrapped around it. Its pretty basic, but useful.

I have most of the supplemental plugins ported over for use in BH2 (assuming I don’t change how plugins are defined again). So things like jumping between the two bracket ends, folding by brackets, swapping quotes, swapping brackets, etc. is working (some of the tag stuff not yet).

I still have some stuff to work out though. Currently I don’t have searching of brackets inside strings enabled yet, I have to figure out if I want to just allow basic bracket searching via an external plugin, or allow some kind of recursive bracket matching inside scope bracket matching. And other stuff. I am sure even after the beta, it will need some refining, but good progress has been made.

[facelessuser]

Looks like I should have an alpha out within the week.

-It now can match almost any unlike brackets you define (think {}, ], #if/#endif, etc.)
-It can find most any like brackets you define if they are contained in the common scope. (think quotes, etc.)
-If you have a matched scope type bracket pair, you can also find sub brackets (think finding (), {}, etc. inside quoted strings)
-You can wrap selections with brackets of your choice, even slightly less brackety things like #if/#else/#endif and it will properly indent all elements added.
-You can remove simple brackets so anything thing with only a start cap and or an end cap, (think {}, ], #if/#endif…but not #if/#else/#endif)
-When wrapping brackets you have the content blocked off, or blocked and the content indented
-You can swap brackets. It replace them inline no formatting. But it can do things like turn a #if/#endif into a #if/#else/#endif and indent the extra item.
-You can swap quotes and it will take care of proper escaping of quotes inside the string.
-It can jump between bracket end caps.
-It can select content between brackets.
-Fold the bracket content.
-Find tags.
-Select tag names in both the opening and closing tags for quick and easy changing.
-Jump between opening and closing tags, and jump between tag attributes.

So a lot of stuff it could already do, but some new stuff as well. The big thing being a increased performance (based on the testing I have done so far), and increased configurability so people can finally configure any bracket they want. Also the new wrap brackets around selection feature.

The last thing I need to really figure out is how to properly take care of specific cases such as strings where you don’t want to find escaped brackets in a regex string, just the unescaped brackets. Because everything is so generalized now (so people can define the matching for anything), I am trying to think of a generalized way to define this so I am not hard coding it and interfering with scenarios where this is not desired.

But anyways, things are looking pretty good. Hopefully testing can begin in this next week.

[Eduan]

Just wanted to say, I am looking forward to this plugin, and using it.

[facelessuser]

Just wanted to say, I am looking forward to this plugin, and using it.

Thanks! I have been avoiding the re-write, but I know a lot of people have wanted more flexibility. Hopefully this will live up to people’s expectations; it has been a lo of work .

[Eduan]

[quote=“facelessuser”]

Just wanted to say, I am looking forward to this plugin, and using it.

Thanks! I have been avoiding the re-write, but I know a lot of people have wanted more flexibility. Hopefully this will live up to people’s expectations; it has been a lo of work .[/quote]

I hope so too. I’m sure I’ll use it though.

Just a question, I still can’t understand exactly what this plugin is for… I understand it’s to customize the way brackets etc. light up, depending on your settings, is this right?

[facelessuser]

This is a re-write of BracketHighlighter. Originally BracketHighlighter was written by Pyparadigm (it was called something else though). Anyways, I increased performance on it and added a number of features which never got pulled in, and eventually Pyparadigm removed his original package.

BracketHighlighter used the core algorithm that Pyparadigm put in place, but it was limited to {}, ], (), and tags (which triggered off of <>). It was very specific and not very flexible. I was able to squeeze in quotes, but it was all hard coded. I kept getting requests for other types of brackets or bracket like matching, but the algorithm could not support it easily at all.

So, I was left with telling people I could not support their request, or re-write the algorithm to support it. A complete re-write is a lot of work, so I have put it off for quite a while. This is what BracketHighlighter2 is. BracketHighlighter 2 is a complete re-write that allows users to configure automatic matching of whatever they need. Quotes, brackets, #if compiler switches, ruby if/end blocks, CSSEdit @group stuff, tags, and whatever other bracket like matching that is desired with minimal effort from me or the user. Now you can just define the rules in the settings file, and BracketHighlighter 2 will take it from there (really tricky stuff can tap into bracket plugins to accomplish the task).

An added benefit is the algorithm is seems faster overall.

In short BracketHighlighter 2, if all goes well, is meant to be the successor of BracketHighlighter; it will replace the old BracketHighlighter. Hopefully, everyone will like it much more. As long as performance for everyone is as good or better, this will be the new version. Which is why I need people to test it and real feedback. It is meant to be BracketHighlighter, but more configurable and faster.

[Eduan]

OK, that makes it very clear.

Whenever you get the beta out, you can count on me, just send me a PM.

[facelessuser]

[quote=“Eduan”]OK, that makes it very clear.

Whenever you get the beta out, you can count on me, just send me a PM. [/quote]

Will do. I should have a beta out this next week. BH2 now does everything the old one did (except for maybe one or two minor things I have removed for now). I plan on tweaking the code for the new feature of wrapping brackets around a selection, and then I will create a testable branch.

[Eduan]

Awesome! Looking forward to it.