[uoaei]

In what world would it be needed to prove the value proposition of "users can see which open brackets are associated with which close brackets"? Thus just seems blindingly obvious to me and probably anyone who's spent more than 40 hours writing code.

> It's silly to be bashing it as a "slow" Electron app when it's measurably way faster than XCode

One of my favorite mis-applications of opportunity cost from the perspective of developing features, and one I see constantly in market-brain types: the comparison is not on competing offerings but on whether the feature is present or not.

[bilalq]

Maybe blindingly obvious in hind-sight, but none of the IDEs I mentioned in my last comment have this feature. Nor does any other IDE I've ever used. It's not hard to imagine why a novel feature, without much prior art, potentially sitting on the blocking path for UI rendering, and contributed by an external person would face friction in being merged into core. Not to mention the onboarding complexity of making a change like this in core vs as a standalone extension for a new contributor.

Also, I don't understand at all what your last sentence there means.

[b5n]

It's always entertaining to me to see 'new'(ish) IDE features being lauded that have already been available in emacs for years, if not decades.

[vladvasiliu]

After a quick search through the settings, IntelliJ seems to indeed not have bracket colorization. I seem to remember there was an option for this, but it may have been a 3rd party plugin.

However, it has something that I find superior: when you're on a bracket, it will highlight its opposing bracket (closing if you're on opening, and vice versa).

The reason I think it's superior is that you can see directly which specific bracket you're looking for, you don't have to hunt for the corresponding shade. And in case your brackets are unbalanced, you'll see it directly.

[SketchySeaBeast]

> In what world would it be needed to prove the value proposition of "users can see which open brackets are associated with which close brackets"?

One where there is finite time and resources and you have to pick and choose what you tackle. I could easily see this being ignored knowing that VSCode is so extensible and the community could easily pick up the missed non-core functionality until there was time to do it right.

[jve]

> seems blindingly obvious

Well, for me it IS helpful when the code block doesn't fit on single screen and I have to scroll AND there are multiple levels of brackets. Usually I try to put a cursor and not move it vertically and scroll to see where it ends. And coloring helps here.

Sometimes I want to understand - hey, where is the closing bracket, because there are 3 openings on single line, some expressions formatted on some lines, typecasts and whatnot that litters () around. Format document may not help there to align everything if I got any bracket missing there.

And I usually exit early, trying not to make too nested constructs, not using excess (), prefer constructs that eliminate brackets altogether. Anyways, not always we read our code. Of course python people can laugh that they don't even have such an issue, but others have, you know.

[EMM_386]

> Well, for me it IS helpful when the code block doesn't fit on single screen and I have to scroll AND there are multiple levels of brackets.

Maybe they'll port this feature to VS Code.

I tried it out, solves the problem you mentioned.

https://devblogs.microsoft.com/visualstudio/sticky-scroll-st...