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

edit from @hediet, details from this comment:

image

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:

image

window.zoomLevel deleted:

image

Restoring window.zoomLevel and deleting editor.fontFamily instead:

image

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.

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Reactions: 3
  • Comments: 16 (6 by maintainers)

Most upvoted comments

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.

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.