Bracket pair colorization should NOT be enabled by default

[aradalvand]

A recent update added a native bracket pair colorization capability, and it's enabled by default.

I don't like this thing at all and I find it to be confusing, and although I can of course disable it manually, I think enabling it by default is a bad idea.
Mainly because this is a "niche" feature, so to speak, most people don't use/want to use it, it would've been better if you just offered users this feature without messing with the defaults.

Please keep this feature disabled by default.

[gjsjohnmurray]

most people don't use/want to use it,

Do you have evidence to support this assertion?

[aradalvand]

@gjsjohnmurray No, not concrete evidence, but by making the decision to enable this option by default, you guys are implicitly making the opposite claim, which means you are more obligated to provide evidence for your claim than I am for mine, as you were the ones actively making a change, requiring sufficient justification.

Also from a commonsense standpoint, again, I don't think enabling fancy features like this BY DEFAULT makes much sense. Although it's nice, albeit unnecessary, to have such features built-in — so as to eliminate the need for third-party extensions like this — enabling it by default seems like a strange decision.

[lorand-horvath]

I find the bracket pair colorization feature extremely useful for productivity, so I do welcome it being enabled by default.
To each his own, as they say.
Anyway, it can be disabled very easily: Preferences > Settings > Text Editor > Bracket Pair Colorization: Disable - it takes about 10 seconds, 5 if you've done it more than once :)

[mafredri]

I'd like to provide a personal account here: When this feature was enabled I didn't even realized VS Code had been updated, simply that my custom color scheme had broken. I only use a few shades of white/gray and avoid reliance on colors as they are distracting to me and I find code clearer without them. I probably wasted about 15-20 minutes first trying to fix my theme, then trying to find a theme in the marketplace that isn't "broken" and finally landing on that this was caused by a new setting.

I'm not for or against this being enabled by default, just wanted to give you an account of a user experience gone wrong.

I think #148859 is relevant here since currently a lot of low-color themes seem broken in the marketplace when this feature is enabled.

[gjsjohnmurray]

@mafredri do you remember whether or not the 1.67 Release Notes tab opened automatically for you? I have seen a couple of reports so far which indicate there may have been a problem with that. For example #148884

[mafredri]

@gjsjohnmurray I never saw the release notes, but I can't dismiss the possibility that they could've been opened in some other window (I can't recall if I had multiple). Usually I've seen the notes, and have the setting to show them enabled.

[gjsjohnmurray]

Pinging @joaomoreno with another instance of release notes perhaps not showing up.

[fuweichin]

Yes, currently "Bracket Pair Colorization" seems to be buggy and confusing.

Taking javascript syntax highlight as an example:

1. parenthese pair color of function invocation may vary
2. parenthese pair color of arrow function may vary
3. ...

Since I upgraded VSCode to 1.67 without reading release notes, it caused me wasting 1 hour to troubleshoot, like this:

1. Disable all extensions, restart VSCode, uninstall all extensions, ...
2. Uninstall VSCode, delete VSCode leftover directories (appdata/settings), restart Windows, ...
3. Reinstall VSCode, ...

What a pain!

Please don't enable it by default for now.

[gjsjohnmurray]

@fuweichin this is the designed behaviour. Colours represent nesting depth, not semantic meaning of the brackets. As well as the setting to disable the feature entirely there are ones for setting colours for six levels.

[abhijit-chikane]

Well, sorry but I disagree with your opinion. As @lorand-horvath @gjsjohnmurray commented indeed it is very useful and it should must be there in the first place in VS Code. But I saw there is bit a contradiction on this point due to the color view of these brackets

1. That makes my code too much colorful
2. Most of the times it will not match the theme that they have setup.
3. Somebody like me prefer the horizontal bracket pair guides

• "editor.guides.bracketPairs": true,
• "editor.guides.bracketPairsHorizontal": true,

Even me when I first installed the new update I thought the same way that it should not be there by default as It confused me so I looked up my theme If something is going wrong with that then I read the release notes where I came to know this is feature added in new release.
I think rather than removing this setting as default from VS code, VS Code team should give a option to choose in betweeen the horizontal horizontal bracket pairs guides or bracket pair colorization one and once after that they should give easy way to customize these colors(dropdown of few default bracket colorization themes would be nice touch. Personally I don't like the pink color in it).
And I also think whenever VS Code pushed updates it should be have a tour(walkthrough) of new features as it is in most of the popular applications(So that these changes would be possible to track to end user if that is a bug or new feature added in VS Code)
Last but not least and most imp. You people are doing really great Job!!!

Thanks
Be safe, Be kind

[abury]

Just to add my 2c, I'm sure that it's useful to some people, and that some very talented folks worked very hard on it, but it was VERY jarring to open VScode the other day and not know why everything looked wrong. I personally really don't like it, mostly because it makes it harder to read due to the addition of new colors to everything.

I definitely agree that something like this shouldn't be enabled by default. I didn't see any release notes, but even if there were, VScode updates so regularly and usually has quite a number of changes that i likely wouldn't have seen it in there anyway.

From a UX perspective, if a user has set up their IDE to be displayed in a certain way, it's unpleasant for it to all of a sudden look different.

[aradalvand]

From a UX perspective, if a user has set up their IDE to be displayed in a certain way, it's unpleasant for it to all of a sudden look different.

Well said.

[michaelmcleodnz]

I agree this shouldn't be the default. With the exception of perhaps LISP, the level of nesting is pretty far down the list of important things I need to know about my code. In fact, I'm sure the whole reason brackets have been a neutral grey until now is because it was recognised that the syntactic structure should get out of the way and allow coders to focus on the semantics. Many herald Python as clean and simple precisely because it does away with some of these brackets. (I know, not solely for that reason.) Making the brackets the brightest multicoloured aspect of the file, and not even linking the colour to their usage in any way beyond the level of nesting, makes my code not only feel tacky and garish, but actively distracting. Maybe if the colours were subtler than the carefully chosen palette used for important code, then I could tolerate this becoming the default for every file of every VSCode user in the world. As it is, I can imagine some people loving the feature, and would be happy for them to continue enabling it in settings (probably on a per-language basis). I'd just be surprised if they were in the majority.

Sorry for the rant; your developer team is great, and if I didn't already recommend VSCode to so many people, then I wouldn't have been so horrified to see this hideous unicorn vomit on my computer without my permission.

[L0v3l4c3]

Completely agree, I am quite surprised this ever made it into the release as a default feature. I am sure many people use it, but in my case none that I know of, and as a matter of fact we find it hideous and distracting. Please keep this feature disabled by default.

[ponderingexistence]

I opened VS Code the other day and saw the colorized brackets and it immediately made my eyes bleed...
I absolutely hate this and I find it extremely distracting. I understand it can be disabled (and I did so without hesitation of course, to stop my eyes from bleeding), but it makes no sense to shove it down everyone's throat all of a sudden. Shouldn't be the default as most people won't want their IDEs to look like this, it's not the norm.

Please revisit this decision.

[xuxucode]

I thought the theme is broken, looks not better.

[scholtzm]

Although I do find the feature useful, my first instinct was that my theme was broken. Perhaps there's a better way to introduce features like this in the future.

[mafredri]

Although I do find the feature useful, my first instinct was that my theme was broken. Perhaps there's a better way to introduce features like this in the future.

I had a similar thought. For instance, it'd be pretty cool to have a feature preview with an option for "yes I want to enable this". Maybe not be feasible due to added complexity though and should be reserved for breaking features. I realize many might not even think of color additions as a breaking change, but really it is unless it falls back to not changing the visuals.

Another approach here would've been to allow themes to opt-in to this functionality with the ability for the user to force it on (via settings).

[hediet]

Another approach here would've been to allow themes to opt-in to this functionality with the ability for the user to force it on (via settings).

This is something we are thinking about to explore too.

[cartermp]

I love this change and I'm glad it's the new default!

[RikkiGibson]

I was definitely thrown for a loop and had to go digging in the release notes to figure out what was going on. Now that I understand what it is and what it's doing I'm excited to try using it.

[davidwengier]

Chalk me up as another person who thought my theme was broken. Glad to find out from this issue where the option is to turn it off though.

I definitely did get the release notes tab, but I closed it without reading it as I always do.

[cweijan]

I know how to turn it off and do that, but I don't think the option should be enabled by default because the colorful brackets distract me.

[gjsjohnmurray]

it'd be pretty cool to have a feature preview with an option for "yes I want to enable this"

Could walkthroughs be used to highlight features in each new release which existing users may want to opt in to?

In #149399 @misolori is currently looking at how these work for first-time VS Code users.

[mafredri]

@cartermp This issue is about looking outside yourself and your preferences. It does not help the discussion that you are posting single sentences about your preferences. If you want to contribute, at least motivate clearly why it should be the default, the counter argument is that you can just go to preferences and enable it. There have been many long motivations in this thread as to why it should not be the default.

[aradalvand]

I think it should be the default. It is extremely useful to me.

@cartermp I literally just talked about how expressing your own personal preference and liking of this feature has very little relevance to the question of whether should it be enabled by default for EVERYONE or not! — in this comment.

[lorand-horvath]

Good God... this issue really got out of hand. Who would have thought that people have so much free time on their hands to write and write and write some more, complaining about this minor problem?

I mean no offense, but it is really only one single setting to switch if you want bracket colorization off, FFS:
Preferences > Settings > Text Editor > Bracket Pair Colorization: Disable

[nodren]

I mean no offense, but it is really only one single setting to switch if you want bracket colorization off, FFS: Preferences > Settings > Text Editor > Bracket Pair Colorization: Disable

Everyone is well aware how to disable the feature. The issue has nothing to do with "how" but rather "why" it was enabled by default in the first place. the "how" is completely irrelevant.

[cartermp]

Who would have thought that people have so much free time on their hands to write and write and write some more, complaining about this minor problem?

Agreed.

[mafredri]

@lorand-horvath @cartermp Did you miss the discussion here about how to handle these kinds of breaking changes in the future? I think some great progress was made in that regard. And I can't help but wonder how you'd react when it's a feature you disagree with. 😄 At that point you may be glad we had this discussion now about how to deal with these things in the future.

[aradalvand]

@lorand-horvath You can ignore this issue if it doesn't concern you. Which features are turned on by default matters a great deal, if you think this is a "minor problem" then there's no reason for you to comment on this issue. Everyone already knows you can enable/disable these things, that has zero relevance to the discussion here. Your comment is redundant and doesn't help.

[lorand-horvath]

@aradalvand Never mind, you're on a roll!

[Yarakashi-Kikohshi]

I am using this Bracket Pair Colorization. I had been using bracket pair colourizer before this feature was released, so the move to this feature was inevitable.

However, it is negative whether it is enabled by default. It should NOT be enabled by default. Such changes are confusing for users.

This feature is meaningful for those who had previously used the extension (bracket pair colorizer etc.), but can be meaningless and harmful for those who did not use the extension. This feature needs to be enabled by the user with the same intention as installing an extension.

Thanks to all those who have contributed to the past and future development of this feature.

[abury]

Good God... this issue really got out of hand. Who would have thought that people have so much free time on their hands to write and write and write some more, complaining about this minor problem?

I mean no offense, but it is really only one single setting to switch if you want bracket colorization off, FFS: Preferences > Settings > Text Editor > Bracket Pair Colorization: Disable

Yeah, imagine caring what happens to a tool you spend 35+ hours a week staring at and taking a few minutes out of your day to try and contribute to how decisions are made regarding it's feature development. Complete and utter waste of time... /s

People clearly do care, and things like this have a measurable impact on productivity (and therefore $$$). Nothing wrong with having a conversation about the pros/cons about it. Now the VSCode team is aware of the impact on things like this and will (hopefully) take it into consideration when releasing new features.

Time well spent I'd say.

[NotoriousPyro]

I don't like this thing at all and I find it to be confusing, and although I can of course disable it manually, I think enabling it by default is a bad idea. Mainly because this is a "niche" feature, so to speak, most people don't use/want to use it, it would've been better if you just offered users this feature without messing with the defaults.

Please keep this feature disabled by default.

I completely 100% disagree. I didn't even know this was a feature but now I am excited to see it.

Countless hours have been wasted from brackets in wrong order, only to be found after running a program and then staring at the line in question, if this can be identified easier by default, it's amazing.

parenthese pair color of function invocation may vary
parenthese pair color of arrow function may vary

I'm not sure why this is confusing? There's only one pair of parenthesis on any of these parameters? Why does it matter what colour it is?

All arguing against this feature, go use Notepad to edit and see how difficult it is to identify where certain things start and end... Because it's all black text, similarly all the brackets before this feature are white... With python and without this feature all you see is a little red squiggly line...

[nodren]

I completely 100% disagree. I didn't even know this was a feature but now I am excited to see it.

If it's disabled by default, you could have easily found it on the release notes and enabled it, like they normally do with new features.

Anything you're saying about the usefulness of this feature is completely irrelevant, no one is debating that, no one cares about that. the issue is strictly if it should be enabled by default or not.

All arguing against this feature, go use Notepad to edit and see how difficult it is to identify where certain things start and end... Because it's all black text, similarly all the brackets before this feature are white... With python and without this feature all you see is a little red squiggly line...

We're arguing against it being turned on by default. no one is suggesting the feature itself doesn't have value.

[aradalvand]

All arguing against this feature, go use Notepad to edit and see how difficult it is to identify where certain things start and end... Because it's all black text, similarly all the brackets before this feature are white... With python and without this feature all you see is a little red squiggly line...

Please try to understand what this issue is about first.
If you like this feature, good for you, nobody's trying to take it away from you. We're just suggesting that it doesn't make much sense for features of this kind to be enabled by default. That's all. If you have any arguments against THIS, then go ahead, if not, then we don't need anyone to tell us how much they like this feature.

[NotoriousPyro]

All arguing against this feature, go use Notepad to edit and see how difficult it is to identify where certain things start and end... Because it's all black text, similarly all the brackets before this feature are white... With python and without this feature all you see is a little red squiggly line...

Please try to understand what this issue is about first, you're making no sense. If you like this feature, good for you, nobody's trying to take it away from you. We're just suggesting that it doesn't make much sense for features of this kind to be enabled by default. That's all. If you have any arguments against THIS, then go ahead, if not, then we don't need anyone to tell us how much they like this feature.

You're implying I don't understand what the title is about, which is pretty clear.

I like the default. I'm arguing for it to be default.

[aradalvand]

@lorand-horvath Bombarding every comment with thumbs downs doesn't help you prove your point or strengthen your arguments.

[lorand-horvath]

I think I'll post this thread on my blog for the public to see where 'development' and 'developers' have arrived to. Found the perfect spot for it, it'll fit right in. Perhaps reddit as well...

[nodren]

I like the default. I'm arguing for it to be default.

you like the feature, which in a real world scenario you could just turn on. the point others are making here is it's a feature turned on by default that didn't previously exist, that effectively changed the look and feel of the software from people who had previously configured it to their taste in ways they didn't expect.

If you're wanting to defend why it should be default, make a case for why it should be default, just "liking" the feature isn't enough. There's plenty of features of VS code i like(font ligatures for example, or render whitespace) which are not enabled by default. I would never advocate any of them to be the new default option.

Here's a fun experiment. Find a VS Code feature not enabled by default you don't like, which affects the visual style of VS Code. Maybe it's a white background, maybe it's font ligatures, or render whitespace, or the git lens extension's blame comments on the active line of code. Now that we're talking about a feature you don't like, make an argument for why it should be enabled by default in the future.

Obviously that's a terribly hard argument to make, because the point is this: No one cares that you or anyone else likes the feature. No one cares that others don't. Just don't make it the default. I've yet seen an argument from anyone here on why this should be the default that goes beyond "Well I personally like the feature". I've seen plenty rational arguments from people who both like and dislike the feature who've clearly explained why it's a bad idea to make it a default.

[cartermp]

just "liking" the feature isn't enough.

Actually, that's precisely enough justification for supporting a design decision like this. Disliking a feature is also precisely enough justification for not supporting a design decision.

[nodren]

just "liking" the feature isn't enough.

Actually, that's precisely enough justification for supporting a design decision like this. Disliking a feature is also precisely enough justification for not supporting a design decision.

What design decision exactly, because I reiterate, this isn't about the feature but about the feature defaulted on.

Several people above who like this feature would disagree with you that it should default on. So no, your comment makes no sense and is completely short sighted of the actual issue.

[mafredri]

I think everything that needs to be said has been said at this point. Let’s give the vscode team a breather while they ponder on what they want to do about it.

[MSLeiter]

Intro

Given the fairly divided and strongly opinionated views on this, I will suggest another alternative:

VS Code should have a "new feature pop-up" feature

Pop-up offers configuration options when any new feature can change UI behavior

When a new feature is introduced, and there is either a set of possible options for that new feature, or there is a change in defaults, then:

1. The user should get a pop-up after install informing him of the change, and providing the ability to pick one of the new available configurations
2. The popup should show which setting/config is the new default to allow them to easily choose what the dev team believes is the best default setting

The intent would be to only provide a pop-up when it directly changes the end-user experience, especially when it could be confusing to the user due to a change in defaults, like the color bracket option provided. Therefore, it may only be required on something like 20-30% of released features, as many are extension developer and power-user types of updates.

The goal is to give special attention to the normal end user to highlight changes that give new UI options or would impact their UI experience or custom setup in VS Code. I suspect many users are just using VS Code to do daily work and may not feel it is worth their time to pour through every set of release notes, or rarely updates VS Code due to occasional bugs introduced and can't afford to read all the intervening release notes.

At the same time, this would provide a means of highlighting the most relevant and significant changes in the releases, which would save a lot of time of the average user in reading the release notes in great detail to avoid missing things like the color bracket default change.

New global option for this feature

A new global option should be added to control the behavior of this new feature with something like the following choices:

1. (default) Show pop-up all new features that have a new or updated configuration setting and give option of any new settings when VS Code is updated
2. Show pop-up of only new features that impact my UI directly (i.e. changed an existing settings or change the way my UI works due to a new feature)
3. Show only a release notes window (current behavior)

[avicularian]

Whoever submitted this PR request, it took them all of 5 seconds to change one "false" to "true" in the configuration files (little other effort was expended).

The result of this is hours of confusion for many VSCode users, possibly over a million hours of wasted time in total.

Please don't do things like that.

Not only is the sudden change annoying and confusing, but the feature—as it is—is under-baked and limited in options. The default colours are ugly (3 colours, with no gradient between each of the colours, and also the most lurid/garish choice of colours possible) and moreover the options to customize are very limited, which causes more wasted hours for developers. There are a maximum of 6 colours to enable, whereas the classic Bracket Colorizer extension allowed for much more (as many as you want, if I remember).

So in enabling this "native" colorization, the developers of VSCode actually annihilated needed functionality for a huge number of users.

The lack of colour choices is clearly contributing to the annoyance, as can been seen in the huge number of issues where users simply do not understand the purpose of the colour change.

A basic "rainbow" colour scheme would remedy that, as it allows for a much clearer, gradiated display of where you are in the nested bracket hierarchy—it is immediately obvious what purpose the colours serve. But a basic rainbow colour scheme is impossible with the current configuration. There are 7 colours in a rainbow.

Please fix this mockery of a "feature" and try to refrain from disrupting user's precious coding time in the future.

[CAD97]

I want to propose a middle-ground solution:

What imho would've been the ideal situation would be to have made enabling bracket colorization the choice of the color theme by default. This offers the benefits both of default-on and default-off:

• If a developer has a custom color theme, their color theme would not change.
• Theme designers wouldn't need to update their theme immediately upon release of the feature to replace the default colors with theme-appropriate colors¹.
• The feature would still get widely used, as it is enabled by default for users of the default theme(s) provided by vscode.
• A three-state toggle could still be provided between theme, off, and on for bracket colorization to respectively
  • use the theme's decision (default off if the theme has not enabled bracket colorization),

At this point, though, it seems to me not super productive to turn off bracket colorization by default, as at this point any theme maintainer will either have selected theme-appropriate colors or disabled bracket colorization for the theme. Changing the default at this point would just serve to make everyone currently happily using the colored brackets to turn the setting on.

For any future changes to color theming, however, it would still make sense to prefer to not change how themes display without the theme opting into the new theming feature(s) when doing so is practical.

Footnotes

1. Although note that it is possible for theme authors to effectively disable bracket colorization for their themes with the feature as originally released by setting editorBracketHighlight.foreground[1-6] and editorBracketHighlight.unexpectedBracket.foreground to the same color. ↩

[aradalvand]

Update:
It's now been many months since this feature has been introduced and enabled by default and now suddenly disabling it would once again violate people's expectations and cause annoyance, my intention for this issue was to convince the maintainers to revert the decision to have it enabled by default shortly after it was made, now, that can no longer happen, because a relatively long time has now passed.

This, coupled with the fact that I've recently turned on this feature and actually started to like it, has led me to believe I should probably close just this issue. Although I'd be open to the possibility of reopening it again if there's sufficient demand for that.

Thank you everyone for your participation.