Vertical bracket pair guides are invisible on non-indented lines. They can't draw in the gutter I guess.

[aminomancer]

edit from @hediet, details from this comment:

Anyway, I figured out the problem, bizarrely. Changing the font family or the zoom level somehow breaks rendering of the line. Look at the settings:

window.zoomLevel deleted:

Restoring window.zoomLevel and deleting editor.fontFamily instead:

So apparently we are looking at a layout bug. Maybe due to window scaling factor + subpixel rounding issues, that seems plausible.

---

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: 1.63.0 (user setup)
• OS Version: Windows_NT x64 10.0.19042

Steps to Reproduce:

1. Follow the steps outlined in the change log to enable bracket pair guides.
2. Open a file with brackets and multiple lines between them. A vs code settings file (settings.json) is a good example since you'll need to open it to set these settings anyway.
3. Make sure the brackets are not indented at all. Like, no control characters before the bracket. If both brackets are the first character on the line, their vertical bracket pair guide is invisible.
4. In settings.json it's easy to see, as the settings are all in a single object. There is no vertical bracket pair guide visible. But if you just hit Ctrl+A and Tab, suddenly the bracket pair guide is visible.

I did read the changelog for the Oct and Nov updates, and the whole blog post on the new bracket pair colorizer feature. I searched vigorously for a setting I might have missed, so I don't think one exists. I believe it's worth adding one. Well personally I think showing guides for all lines should be the default behavior, but maybe that's more controversial than I think. I can understand how it might seem superfluous or even annoying if you're dealing with a large file where everything or almost everything is wrapped in a single bracket pair, like an HTML file (although I think bracket pair guides don't even show for HTML tags by default).

I believe the inconsistency looks a little sloppy, like it might be an accident (not saying it is, but I usually try to avoid the appearance of unintended behavior). Functionally it's not a huge deal, but sometimes it makes a difference. For me, if I'm working with javascript modules, often there are gonna be a lot of top-level functions, objects, classes, etc. For procedural style modules, sometimes it's a very big file and even though there is a great number of top-level blocks, many are still long enough that the contents can't all fit in the viewport at once. I use 4 spaces for tabs for this exact purpose, but tab size 2 is the norm in most projects I work on or with. So the bracket pair guides are helpful to me for just being able to see at a glance whether I'm still looking at a single block.

I heard about the bracket pair guide feature a little late, from reading this article, which makes the new feature seem like a complete substitute for similar extensions. Before this feature was added to VS Code, I was using this extension. It included a setting bracket-pair-colorizer-2.showBracketsInGutter which does what you'd expect. So I'm inclined to continue using that extension, even though it's much slower and has visual bugs.

[gjsjohnmurray]

/assign @hediet

[yume-chan]

I tried Bracket Pair Colorizer 2 but I didn't see how it works differently from the native implementation. Can you include a screenshot?

[hediet]

Yes, a screenshot of the current behavior and the desired expected behavior would be nice.

[silkfire]

Are you sure this is an error? Vertical indent guide in the far left margin works for me when all lines are unindented:

This statement seems to be contradicting itself:

3. Make sure the brackets are not indented at all. Like, no control characters before the bracket. If both brackets are the first character on the line, their horizontal bracket pair guide is invisible.

Either the brackets are the first characters on the line, or they are indented (i.e. whitespace comes before them).

I think the bug you're referring to is that if both brackets are on the same line, no horizontal guide is visible when the caret is between the brackets:

BPC2:

VSCode Native:

Instead, the parent bracket pair has the indent guide.

[aminomancer]

No, like the title and the body of the post both say, I'm talking about the vertical line. The horizontal line works perfectly fine for me. You have to switch a preference, editor.guides.bracketPairsHorizontal. Read the articles I linked.

Anyway, I figured out the problem, bizarrely. Changing the font family or the zoom level somehow breaks rendering of the line. Look at the settings:

window.zoomLevel deleted:

Restoring window.zoomLevel and deleting editor.fontFamily instead:

So apparently we are looking at a layout bug. Maybe due to window scaling factor + subpixel rounding issues, that seems plausible.

[aminomancer]

For what it's worth, for window.zoomLevel the minimum value above 1 (my desired zoom level) that results in the vertical line being visible on the gutter (as desired) appears to be an irrational number. I'm not gonna spend eternity on trial & error for this but I went down to 8 decimal places: "window.zoomLevel": 1.03200074

Which makes me even more suspicious this has something to do with subpixel rounding.

Edit: I went a little deeper: "window.zoomLevel": 1.032000735876186570117

Idk if someone's capable of doing some calculation with that to arrive at a clue. This might also be fixed by #135114, if there was some space between the first encoded text column and the right edge of the gutter. I did try removing the background color of the gutter with the theme API by the way, doesn't seem to work. So it appears that the gutter isn't overlapping the editor text area even by a subpixel amount. Idk if that bodes well for the possibility of fixing this with horizontal padding but it's worth a try, if only because adding horizontal padding would fix that issue as well.

[aminomancer]

By the way, as for your complaint about step #3, I am really not sure what you mean. That is the whole point. I'm saying to get rid of any characters on the line preceding the brackets, so that the bracket guide will be drawn on the very first column. That's the goal. I described it in two ways to increase the chances of people understanding what I'm talking about. I'm not saying either/or, I'm saying "Make sure the brackets are not indented at all. In other words, no control characters should exist before the bracket."

I guess the reason you didn't reproduce this is because it doesn't happen with the default window.zoomLevel.

[silkfire]

I'm using the active setting for editor.guides.bracketPairsHorizontal and yet a bracket pair on the same line does not yield a horizontal bar. Can you reproduce that?

[aminomancer]

Yeah I do see what you're talking about. Separate issue but yeah I agree that's a deviation from BPC2. I assume someone just decided bracket pair guides aren't necessary when everything is on a single line. I guess whoever made that decision hasn't spent much time reverse engineering minified code. Or maybe it's a performance thing.

[hediet]

I guess whoever made that decision hasn't spent much time reverse engineering minified code.

I recommend using a formatter that can generate a source map for that.
But this does not have much to do with this issue, so lets discuss this in the existing issue for this feature request.

[silkfire]

@hediet Is there an issue up on this missing horizontal indent guide somewhere else, you mean?

[yume-chan]

@silkfire #136475

[aminomancer]

I guess whoever made that decision hasn't spent much time reverse engineering minified code.

I recommend using a formatter that can generate a source map for that. But this does not have much to do with this issue, so lets discuss this in the existing issue for this feature request.

Oh I was just making a dumb joke. But I actually agree that it makes more sense for wrapped lines, or at least lines that are long enough to horizontally overflow the editor if wrapping is disabled. That would be good.

To clarify, I don't think this is just a zoom issue. Because I was able to get the line to appear by either 1) changing the zoom value to something else, or 2) changing the font family. Font faces affect the size of the gutter, presumably because the gutter flexes with the width of the line numbers. So if I pick a font face with different 0-9 glyph bounds, it's gonna change the gutter bounds. Likewise, I guess glyph bounds could affect the column width in which the line is displayed. But either way I think it has to do with subpixel rounding because as I increase or decrease the zoom value or font size, it alternates between showing the line and not showing the line. Which is just like other subpixel rounding issues.

As an example, if I set window scaling to 150% and make a box in HTML with a 1px outline, the 4 edges will usually not all be rendered with the same ultimate width. The 1.5px width for a given edge will be rounded up to 2px or down to 1px depending on where the edge is in the layout. There's a blog post about how Firefox circumvents this in its border property that I found really useful in understanding why this happens. Basically with the box example, if I'm getting 2px on the top edge, I can increase the box height by 0.5px and when it reflows it'll render at 1px. Then if I increase by another 0.5px it'll go back to 2px, and so on.

So I think what I was seeing when experimenting with different window.zoomLevel values is analogous to that. The irrational numbers that were working for me weren't meaningful, they were just changing the layout ever so slightly so that it moves over by half a pixel and rounds up to 1px instead of rounding down to 0px. If something (idk what) was a little different, I think instead of sometimes rendering and sometimes not at all, it would sometimes render normally and sometimes render at double width. The actual implementation is way outside my realm of understanding but I guess it could do something like what Firefox does with border rounding to achieve a consistent width.

[pulasthi-Narada]

Set active in this vs code settings.

[aminomancer]

Set active in this vs code settings.

That's just the setting to enable bracket pair guides. This bug is about bracket pair guides on unindented columns being clipped by the gutter at certain zoom/font size factors. I speculated that it's a subpixel scaling issue.

[hediet]

/duplicate #137367