BracketHighlighter

[facelessuser]

Someone had mentioned that sometimes the gutter icons can get a bit too much, so I have added a setting to disable gutter icons during multi-select.

Someone thanks you

No problem . After you mentioned your issue, it made perfect sense to me, and it really was an easy setting to add.

[phillip.koebbe]

Current highlighting favors what ever is to the left of it.

At the end, yes. When you're at the beginning, it favors what's on the right. Either way, you have to be one character away from a nested bracket in order for the surrounding pair to be highlighted.

ST2s built in bracket underlining is very similar, but actually less consistant which makes brackets not get underlined in certain scenarios.

I chose a very consistant and predictable way to highlight.

Oh, I definitely like consistent and predictable! Ask my wife. Hah hah. Not saying your way is wrong, just that I'd prefer something slightly different. I applaud you for wanting a consistent user experience!

I think this better illustrates what I am doing:

Screen Shot 2012-03-16 at 7.55.21 AM.png

With that said, I can add the logic in, but you may have to wait a little. I have been doing quite a bit of plugin coding recently and I think I need a little break .

Totally understand!

The code is not done with regex...I think regex is the wrong tool for the job here (not to say it possibly can't be done with regex).

Shoot. That's what I get for not looking at the code and just jumping to an assumption. That's one Shame-On-You for Phillip!

I understand thought that not being done with regex doesn't always make the code easier to follow. If you really want to tinker with it and get this functionality before I get to it, you would probably look in adjacent_adjust, string_adjacent_adjust, and the very beginning of I think match_quotes. The first I believe handles brackets intial highlighting, the second handles brackets inside strings initial highlighting, and the third handles quote initial highlighting in the beginning.

Thanks for the pointers. That will save a bit of head scratching.

If you get it working and would like to do a pull request the main things that I require is that it is optional, and you don't break existing logic or functionality (the old method needs to work the same; it took me a little to iron logic out), and brakcets must be highlighted in some scenario no matter which direction the cursor comes from (cursor moving from left and cursor moving form right, the brackets need to fall into a scenario where they will always get highlighted.

That is it. If it is something you don't want to mess with, I will try and get to it sometime soon, just create an issue in github so I don't forget.

Thanks for the detailed response. I might tinker with it this weekend and see what happens. If I get it working the way I want, I'll submit a pull request. Otherwise an issue

[facelessuser]

Current highlighting favors what ever is to the left of it.

At the end, yes. When you're at the beginning, it favors what's on the right. Either way, you have to be one character away from a nested bracket in order for the surrounding pair to be highlighted.

Yes it is not exclusive to the left; it will take whatever is adjacent. But if given the choice it favors the left.

It probably won't be too bad. You could probably just wrap the adjacent call with a conditional block picking one of two adjacent adjust functions (yours and mine). I imagine you would just need a check to see if you are inside adjacent for the adjacent option, and possibly not offset the cursor like it is doing now...I am probably over simplifying, but yeah, it has got to simpler than what is being done now; same goes for brackets inside quotes. The quote adjacent might be a little uglier, it is a little ugly now, quotes were kind of a special case because the logic for them is a bit different.

Anyways good luck. If you have more questions, feel free to ask. I might be feeling lazy, but not so lazy I can't consult to help someone do my dirty work .

[facelessuser]

You shouldn't have to touch match_quotes.

Maybe something like this would work:

Code: Select all

def adjacent_adjust_inside(self, scout):
        # Offset cursor
        offset = 0
        allow_quote_match = True
        # If quotes enbaled, kick out of adjacent check if in middle of string
        if (
            self.view.score_selector(scout, 'string') > 0 and
            self.view.score_selector(scout - 1, 'string') > 0 and
            self.quote_enable
        ):
            return (offset, allow_quote_match)
        allow_quote_match = False
        char1 = self.view.substr(scout - 1)
        char2 = self.view.substr(scout)
        for bracket in self.targets:
            if char2 == self.brackets[bracket]['close']:
                offset = -1
                self.adj_bracket = True
                break
            if char2 == self.brackets[bracket]['open'] and offset != -1:
                offset = -1
            if char1 == self.brackets[bracket]['open']:
                if offset != -1:
                    offset = -1
                self.adj_bracket = True
                break
        return (offset, allow_quote_match)

And this for brackets inside strings:

Code: Select all

def string_adjacent_adjust_inside(self, scout):
        # Offset cursor
        offset = 0
        char1 = self.view.substr(scout - 1)
        char1_escaped = self.string_escaped(scout - 1)
        char2 = self.view.substr(scout)
        char2_escaped = self.string_escaped(scout)
        for bracket in self.targets:
            if char2 == self.brackets[bracket]['close'] and not char2_escaped:
                offset = -1
                self.adj_bracket = True
                break
            if char2 == self.brackets[bracket]['open'] and not char2_escaped and offset != -1:
                offset = -1
            if char1 == self.brackets[bracket]['open'] and not char1_escaped:
                if offset != -1:
                    offset = -1
                self.adj_bracket = True
                break
        return offset

You would need to add in the setting and the logic to use the proper function and just test it pretty good.

I used this in javascript to test basic functionality:

Code: Select all

{[('{[()]}')]}

This should make it easier for you. This code might be what you need without alteration; I am not sure because I didn't bother to test it out too good.

[facelessuser]

Ahh crap. Looks like I sucked myself back in.

The more I thought about it the easier it seemed like it would be...so I went ahead and did it.

Version 1.6
- Add setting to match only when cursor is between brackets

It is isolated with the setting, so even if it isn't perfect, it will only affect those who enable it, but I am fairly confident in it. But feel free to report bugs, or fix it if you find any bugs.

Edit:
I am actually liking these matching rules better than the old ones.

[phillip.koebbe]

Ahh crap. Looks like I sucked myself back in.

The more I thought about it the easier it seemed like it would be...so I went ahead and did it.

I'd be lying if I said I wasn't hoping that would happen

Version 1.6
- Add setting to match only when cursor is between brackets

It is isolated with the setting, so even if it isn't perfect, it will only affect those who enable it, but I am fairly confident in it. But feel free to report bugs, or fix it if you find any bugs.

Edit:
I am actually liking these matching rules better than the old ones.

I'm going to go out and make sure I have the most recent *right now*!

Thanks!

P.S. Not that you need it, but you have my permission to take the weekend off!

[facelessuser]

Small thing I noticed when testing out new bracket matching rules, is that in general, if adjacent_only is set True, internal string bracket matching no longer functions proper. So now if adjacent_only is True and if match_string_brackets is True, the string quote highlighting will be suppressed, but the internal string bracket matching will still be processed with the same adjacent_only rules. Now I am really done, and now I am taking the weekend off .

Version 1.6.1
- Suppress string highlighting when adjacent_only is set, but allow internal string brackets to still get highlighted with adjacent_only settings if match_string_brackets is true

[tito]

I still want to do some more playing around with the icons. For now, here's an HTML 'tag' icon: http://cl.ly/2M1x0e2g141X1Y1I1B3z

Might want to change it later, but that's it so far.

Looks good, Maybe we can add yet another package "GutterIcons" and collect there some nice similar polished icons for the different sizes and possible OS.
Providing an APi or something to use the icons, then other packages use these (if they whish) and the overall application will feel better.
Like 4 different linters using the same icons for displaying errors.

[facelessuser]

Looks good, Maybe we can add yet another package "GutterIcons" and collect there some nice similar polished icons for the different sizes and possible OS.
Providing an APi or something to use the icons, then other packages use these (if they whish) and the overall application will feel better.
Like 4 different linters using the same icons for displaying errors.

It would be really easy to do. I would throw together a repository if I thought someone would use it other than me .

[phillip.koebbe]

Small thing I noticed when testing out new bracket matching rules, is that in general, if adjacent_only is set True, internal string bracket matching no longer functions proper. So now if adjacent_only is True and if match_string_brackets is True, the string quote highlighting will be suppressed, but the internal string bracket matching will still be processed with the same adjacent_only rules. Now I am really done, and now I am taking the weekend off .

Version 1.6.1
- Suppress string highlighting when adjacent_only is set, but allow internal string brackets to still get highlighted with adjacent_only settings if match_string_brackets is true

Hm. I noticed some odd behavior, and that may have been it. I was planning on waiting until the beginning of the week before reporting it (really want you to get some rest!), but I don't think I'll need to now.

The new logic is just what I was wanting. Thank you very much for putting it in so quickly (and saving me from having to wrap my brain around yet another pile of code).

I did notice what appears to be incorrect highlighting involving Ruby string interpolation, but again, I'll wait until next week to report that. And when I do, I'll post a GitHub issue instead of mentioning it here. This thread is quite long now.

Good work, facelessuser. Keep it up (in moderation)!