[Feature Request] Bracket Pair Colorization: Consecutive/independent color mode

[Stanzilla]

This would be porting over said feature from Bracket Pair Colorizer 2

"bracket-pair-colorizer-2.colorMode"
Consecutive brackets share a color pool for all bracket types
Independent brackets allow each bracket type to use its own color pool

[vscodebot]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• Auto closing brackets should try to balance brackets (#6841)
• Marked brackets range on scrollbar (#26604)
• Bracket Pair Colorization: specify where to configure colors (#130993)
• Investigate into the performance issues of the bracket pair colorizer extension (#128465)
• auto closing brackets not working on vscode 1.57 (#127739)

[hediet]

I would change the name of this setting, I don't think consecutive is very clear.

I could imagine editor.bracketPairColorizer.colorizeBracketsIndependently: boolean (default false).

It is easy to implement, but is this feature useful? I would like to have as few settings as possible.

[Stanzilla]

That name name makes more sense, yes. I don't know, I like it personally, maybe @CoenraadS has analytics on how often all the settings were used?

[CoenraadS]

I don't have any data about which settings are popular or not used at all.

[oaahmad]

is this feature useful?

I can't speak for Stanzilla or CoenraadS, but I like this idea for a pretty specific reason. I like bracket colorization when brackets of the same type are nested (because it helps me find pairs quickly), but I find it distracting/jarring that literally every bracket is colored whether it is nested or not. I use VS Code for multiple languages. Some of these use "{ }" for blocks (like JavaScript) and some don't (like Python).

Consider how brackets are colored in the following toy examples:
Python:

JavaScript:

I don't like how busy it looks, and I find it a little distracting. I can try setting "editorBracketHighlight.foreground1" to "#000000" and it looks like this:
Python:

JavaScript:

The Python example looks better, but is flawed. I would prefer to not have any round brackets in that example colored. The JavaScript example looks just as busy as before because everything is in a "{ }" block.

So I want a clean look where brackets are black most of the time (in all languages), but become colored when brackets of the same type are nested. That way I get the benefits of bracket colorization without it being distracting.

Did I explain that well?

Edit: I just realized I have a tuple in the JavaScript example which doesn't make sense (I copied from the Python example), but oh well

[Nahor]

@oaahmad, if the problem is the distraction, it feels to me that you would be better served by just using less saturated/darker colors, so that the brackets are more identical in colors but not quite, and so you can still distinguished them if you need it but without being in-your-face when you don't.

[oaahmad]

@Nahor That would make it less distracting, but it would make it harder to distinguish the brackets when they are nested. The speed and ease at which I can see which brackets are pairs is kind of the whole point of bracket colorization, so I do like that the colors are very different.

It would also be nicer if the brackets were just black when not nested instead of a muted color. It kind of feels like the worst of both worlds: the brackets are still colored when I don't need them to be, and they are not distinct enough when I need them to be.

I do think this feature request is the better solution, but I can play around with colors in the meantime to see if I like something more. Thanks for the suggestion.

[Nahor]

@oaahmad, what you want is not quite the suggestion either. It sounds like what you want is, that first level of color be excluded from the rotating color pool: black-color1-color2-color3-color1-color2-....

Also, it's hard to imagine that this would be a worthwhile feature. How often are brackets not nested? Between the lambdas, functional programming, namespaces, ... it feels like the non-nested brackets would be quite a minority (but I guess that's just my own experience, YMMV)

the brackets are still colored when I don't need them to be, and they are not distinct enough when I need them to be.

How can a color be colorful enough to be distracting and yet not colorful enough to distinguish from others? If you can't find a few color muted enough to not be distracted and but still be distinguishable, it must be hell to be you! 😜

Here another suggestion: have a shortcut to enable/disable bracket colorization (you'll probably need Settings Cycler for that). Then you can keep the colorization disabled until you need it.

[oaahmad]

@Nahor

what you want is not quite the suggestion either. It sounds like what you want is, that first level of color be excluded from the rotating color pool: black-color1-color2-color3-color1-color2-....

That's not quite right. I'm not asking for that because I can already do that. I can already set the first color to black. That setting exists. It does not solve my problem. I already tried it (see my first comment).

The issue is not that I need black to be the first color. The issue is that I need black to be the first color and I need this feature to be implemented.

How often are brackets not nested?

I think you're asking the wrong question. If this issue is implemented, then only brackets of the same type are nested. The right question is "how often are brackets of the same type not nested". The answer is very often with the exception of "{ }" in many languages. I understand that "{ }" will mostly be colored in many languages. I'm fine with that. There will still be a huge reduction in colored brackets.

If you can't find a few color muted enough to not be distracted and but still be distinguishable, it must be hell to be you!

I'm not saying the colors are so distracting that I can't work. I'm not saying the colors are so distracting that I want to disable the feature. I'm saying the colors are distracting enough to me that I would prefer most of the brackets to be black. It's just a preference. You may have a different preference. That's fine.

[Nahor]

what you want is not quite the suggestion either. It sounds like what you want is, that first level of color be excluded from the rotating color pool: black-color1-color2-color3-color1-color2-....

That's not quite right. I'm not asking for that because I can already do that. I can already set the first color to black. That setting exists. It does not solve my problem. I already tried it (see my first comment).

You can set the first color to black, but you cannot remove it from the color pool after the first use. And from your description, it seemed to be what you want (among other things), i.e.:
black-color1-color2-color3-color1-color2-....
instead of
black-color1-color2-color3-*black*-color1-color2-....

Sorry if I misunderstood.

How often are brackets not nested?

I think you're asking the wrong question. If this issue is implemented, then only brackets of the same type are nested. The right question is "how often are brackets of the same type not nested". The answer is very often with the exception of "{ }" in many languages. I understand that "{ }" will mostly be colored in many languages. I'm fine with that. There will still be a huge reduction in colored brackets.

'()' is also nested very frequently , as in func1(func2(func3())), or constructs like while(!empty()). And lets not forget LISP 😛 (but ok, LISP guys are probably using Emacs anyway, not VSCode, so they don't really count 😝).
'[]' is not nested that often in C, but more frequently in Python because Lists Comprehensions.
So yes, I understood you, I just do not agree with the "not nested very often"

If you can't find a few color muted enough to not be distracted and but still be distinguishable, it must be hell to be you!

I'm not saying the colors are so distracting that I can't work. I'm not saying the colors are so distracting that I want to disable the feature. I'm saying the colors are distracting enough to me that I would prefer most of the brackets to be black. It's just a preference. You may have a different preference. That's fine.

What I meant is that for the colors to be distracting, there must be colors that you can distinguish. I can't imagine how you can have distracting colors that you cannot see, which is what you implied with the "worst of both worlds" earlier.

Anyways, my point is that it feels to me, from my anecdotal evidence/experience, like a niche feature. But sure, to each his own.

[oaahmad]

@Nahor Ah okay. I misunderstood what you were saying. Sorry about that. I do not want to remove black from the color pool. I am perfectly okay with black repeating. And yes "worst of both worlds" was not the best wording. I did not mean literally "worst". I just meant it would be a compromise in both directions. My point was just that this feature request would be a better solution because of those compromises.

And yeah I get that this feature will not make bracket colorization exceptionally rare, but the examples you're using are exactly the places where I would want brackets to be colored. My position is just that needless colorization is more distracting than helpful, but colorization is very much helpful when nesting of the same bracket type happens. I do prefer having bracket colorization on even as it is currently implemented because I like the benefits more than I am bothered by the distraction when it's not necessary.

I agree that my reason for wanting this feature might be very niche, and I want to clarify that this feature is not urgent to me. I'm just providing a use case because @hediet asked if this is useful. Thanks for clarifying what you meant about removing black from the color pool.

[oaahmad]

Here is a use case where someone never wants brackets of a certain type to be colored because they are never nested in a language: #132336. This feature request could achieve that.

[hediet]

@oaahmad

So I want a clean look where brackets are black most of the time (in all languages), but become colored when brackets of the same type are nested. That way I get the benefits of bracket colorization without it being distracting.

I like that idea! But I think this is a different feature request, right? (in this case, please open a separate issue)
Would your feature cover the feature requested in this issue?

[oaahmad]

@hediet I can already set the first color to black which is the first step. Black would get repeated in deeply nested brackets, but that's not a problem (not for me at least).

The problem is that many languages use "{ }" heavily for scope. So even if I set the first color to black it makes no real difference because all my code will be inside a "{ }" scope (maybe nested inside several "{ }" scopes).

So what I'm trying to say is this: if I set the first color to black, and this feature is implemented ("colorizeBracketsIndependently") then I have what I want. Brackets would only be colored if brackets of the same type are nested (because I set the first color to black and because I have ("colorizeBracketsIndependently" set to true). So I don't need any feature to achieve this other than the one proposed here. It's just a use case for this feature.

So what I'm asking for would be covered in this feature request to my satisfaction (I just need to use this feature in combination with setting the first color to black).

[hediet]

I understand.
I guess an option like "Don't colorize top most bracket pair per type" would also do it (though we try to minimize the amount of settings).

[oaahmad]

In case anyone is still confused, I finally busted out GIMP and made this monstrosity:

Default settings:

Black:

Black + this feature:

(Except I'd obviously choose better colors than that)

I guess an option like "Don't colorize top most bracket pair per type" would also do it (though we try to minimize the amount of settings).

Yeah I respect your desire to not add extra settings which is partly why I'm advocating for this feature instead of an additional one.

I also just like this better. I want brackets to be colored independently (it's an extra bonus for me).

[Nahor]

@oaahmad, I've added a proposal that could help with some of your distraction issues: #132488.
It's not a replacement for this feature, but it will help further to avoid "unnecessary" change of colors (in your example, it would help for "[["one":"two"]]" and "[[This is a very useless... clear]]")

[NatoBoram]

Personally, the setting I want is forceIterationColorCycle

Too often, you'll have many opening blocks in the same indentation level and they'll all be the same colour. I don't like yellow enough to want it to be everywhere, ya know.

• [Feature Request] Bracket Pair Colorization: Force unique opening color #131029

[OldStarchy]

I also use Indent-rainbow and I have both configured with a sequence of colours that would match the indentation to the braces; see top half of image below.

In order for this to work for the bottom half, I would need the "independent" colour set, otherwise the invocation () causes the colours of the {} to cycle

Although, as a counter-note, I do like that the () in if (true) { are the same colour as the following {}, though we're getting into scope-creep territory here, it would be nice if the {} could reset the colouring of () but not vice versa.

[hediet]

Verification steps:

• Enable bracket pair colorization "editor.bracketPairColorization.enabled": true
• Configure "editor.bracketPairColorization.independentColorPoolPerBracketType": true
• Observe that each bracket type (e.g. (...), {...} in TS) has its own color pool