Hmmm. Interesting. I was about to say that making that line would not be possible but then I realized, Yes it is. It might take some work, but with the custom gutter icons, a straight line isnât out of the question. I personally donât thing itâs that important of a feature but could be an interesting exercise for the gutterâs capabilities.
BracketHighlighter
I donât think it is out of the realm of possibilities, but it does have some limitations.
[quote=âManFromEarthâ]hello, i use BracketHiglighter and i like it alot, can u maybe make this option:
default behavior in notepad++
can u add that red line, so its filling the gap between brackets .to see more clearly block where ur cursor is would be awsame <3[/quote]
To be honest, this would only really work if no_multi_select_icons was enabled. Highlighting multi-select brackets like that would just be a mess; it just wouldnât work with how ST2 does things.
Tell you what, I will look into how good I could make it look with no_multi_select_icons enabled, and if I can get it to look decent, I might add it disabled by default.
in this context, i was trying to recall if in previous Sublime versions the indent guides colored differently to indicate cursor location.
i was actully looking for this option a few months ago, guess it wasnât even there, wasnât it?
[quote=âvitaLeeâ]in this context, i was trying to recall if in previous Sublime versions the indent guides colored differently to indicate cursor location.
i was actully looking for this option a few months ago, guess it wasnât even there, wasnât it?[/quote]
Oh yeah. @Facelessuser, settting indent guides to draw_active is essentially the same thing and a lot cleaner. So you might not want to waste your day fiddling with something thatâs not really important/already implemented.
[quote=âC0D312â]
[quote=âvitaLeeâ]in this context, i was trying to recall if in previous Sublime versions the indent guides colored differently to indicate cursor location.
i was actully looking for this option a few months ago, guess it wasnât even there, wasnât it?[/quote]
Oh yeah. @Facelessuser, settting indent guides to draw_active is essentially the same thing and a lot cleaner. So you might not want to waste your day fiddling with something thatâs not really important/already implemented.[/quote]
Built in only does function blocks, not any bracket block. And trust me, it is supper easy to add (Iâm not looking to spend a lot of time on anything today ):
Cavet: when you space the lines further, they get further apart. But you canât get better than this though, it is a limitation with ST2.
General Impression?
thanks for the tip.
personally i think that indent guides in the gutter would be too much.
That was fast. I, personally, donât like it. Makes the gutter too busy; however, Iâm impressed that it only took you a couple of minutes to implement.
When you know the code well, stuff like this is trivial.
I agree though that it doesnât look good. At least not to me.
Though it was a fun exercise, I think I will hold off on adding the line between brackets. I can add it without affecting people that donât like it, but it does seem unneeded with the current ST2 indentation highlight option. Notepad++ only does the line on foldable regions, and the indentation option in ST2 does the same. So I think what was being asked here is already accomplished in ST2.
I would have to get a lot of people asking for this to support such an option.
i have question regarding tag matching.
does it make sense to you to match tags when the cursor is between tags?
like:
<> |
| |
<> |
currently div tags are matched when cursor is within either one of the opening/closing tags
<>| <div | >
<>|
[quote=âvitaLeeâ]i have question regarding tag matching.
does it make sense to you to match tags when the cursor is between tags?
like:
<> |
| |
<> |
currently div tags are matched when cursor is within either one of the opening/closing tags
<>| <div | >
<>| [/quote]
+1
[quote=âvitaLeeâ]i have question regarding tag matching.
does it make sense to you to match tags when the cursor is between tags?
like:
<> |
| |
<> |
currently div tags are matched when cursor is within either one of the opening/closing tags
<>| <div | >
<>| [/quote]
It makes since, but it is not as easily done. I am kind of doing what I believe ST2 does, first I use the angle bracket matching to find a potential tag, then I see if it is a tag (opening or closing) and then I look for the pair if it is a tag. If you put a cursor in here:
(\w-]+)\s(:)\s**
Do you match the bracket or the tag?
If I added something like this I might take this approach if I find a bracket match before I find a tag, donât search for tag, if I find a tag before I find a bracket match, then highlight the tags. That way in the above example, if I were inside the brackets, the tag does not get matched, but if I am outside the brackets, then the tags would get matched.
Let me play around with this.
i was thinking the same.
match the first bracket you find in either direction, thatâs why itâs called BracketHighlighter
[quote=âvitaLeeâ]i was thinking the same.
match the first bracket you find in either direction, thatâs why itâs called BracketHighlighter [/quote]
Its just fitting it into the algorithm is a little tricky. It was streamlined to do it one way, but to do it the way you are suggesting may take me a while to do well (if I get it working good at all). Also, it is not on the top of my list of things to do since it would also be big headache to make happen.
What I plan to do in the next week is to resolve my current issue with strings:
- I donât like that I am wasting time detecting regex conventions for different languages in strings, and I think it is silly I am highlighting â/â in regex strings. So I am thinking I want to only highlight quoted strings, but still allow the searching for and highlighting of internal string brackets in any non-quoted strings. If no brakcets are found in a non-quoted string, I want to ignore the string and find the next parent bracket. It would be a more generic support for brackets inside any string, and it would support more languages.
- This could also apply to people who donât want to highlight quotes, but still like to highlight brackets inside strings.
Version 1.7
- Hide parent quote highlighting when child quotes are highlighted
- Allow the searching for brackets in non-quoted code scoped as strings (like regex)
- Add setting âhighlight_string_brackets_onlyâ which allows never highlighting quotes but leaves internal string bracket highlighting on
- deprecate âenable_forward_slash_regex_stringsâ in favor of âfind_brackets_in any_stringsâ
Hopefully that all makes sense, basically I just made some tweaks to string highlighting and allow for string bracket highlighting now to occur in any string scope.
Forgive me if this has been mentioned, but Iâd find it epically cool and useful to have multiple bracket types highlighted at once (with only one insertion point) like this:
[quote=âpeppyâ]Forgive me if this has been mentioned, but Iâd find it epically cool and useful to have multiple bracket types highlighted at once (with only one insertion point) like this:
The problem is, BracketHighlighter is designed to minimize how much time it is searching to give you pretty instant highlighting without bogging down your editor. By doing what you suggest, you would have to keep crawling back looking for even more brackets; this would take more time on every search.
Also, I think it would make things more cluttered. The point of BracketHighlighter is to quickly show you what block you are in, but if all the blocks get highlighted, it is not nearly as effective at quickly showing you were you are.
Though opinion may differ on this point, I do not foresee this becoming an addition to BracketHighlighter, but thanks for your interest.
I figured that might be the case. If I get the time I might fork and give it a go to see how it handles performance-wise. I think it is be a matter of personal opinion whether such an addition makes things cluttered or more usable .
Yeah, I understand. Another problem is, it wonât be a simple addition. Everything is streamlined to do it the current way. Anyways, good luck.
Version 1.8.0
- Add new commands: âShow Bracket String Escape Modeâ and âToggle Bracket String Escape Modeâ. Default is âregexâ
Small update to allow you to toggle the string escape mode for string brackets. There are two modes âregexâ and âstringâ:
string escape: \{
regex escape: {
I was kind of annoyed today when I was trying to modify some regex in a string in a JSON file, and BracketHighlighter was getting matches wrong. The current method works great when you are in something like Javascript/Perl regex etc., but not a normal string that is to be converted into regex. So now you can simply toggle to a different escape mode if you need to.