Draw a vertical line between matching braces

[rowbearto]

Notepad++ is able to draw a vertical line between matching braces, as shown in the below screenshot. It is very helpful.

It would be great if SE could also do this.

[WilliamLeara]

I'd like brace indentation guidelines --  faint dotted lines that match up vertically between each open/close brace.  VisualStudio, Notepad++, and UltraEdit all have this.  It's the only thing I miss in SlickEdit!

[Dennis]

You might want to try enabling the Selective-Display bracketing that was added in SlickEdit 2015.

    Tools > Options > Appearance > General > Selective Display

    Document > C/C++ Options > View > Create file outline > Statement level.

We plan to do the indentation guides more dynamically in a future release, but this works quite well at the moment.

[rowbearto]

Thanks Dennis. I tried this and it is certainly an improvement. But I think it would be nicer if the vertical lines would be shown in the same column as the vertical braces instead of stacking them up to the left of the screen (or give the option to choose where to put the vertical lines).

[davehohl]

I agree with rowbearto. It would look much better if the lines were in the same column as the braces.

[rowbearto]

Just a reminder about this feature request. It would be very handy. I see this feature in multiple other IDEs.

[jwiede]

+1 another vote for "inline" vertical lines showing brace scope (not just gutter lines).

[Graeme]

How about just color coding the background of the curly braces like HighlightParens does for parentheses.  Easier to spot than tracking vertical lines and works better when the range of lines is not all visible on the screen.

What does "selective display line color" do?  For me it doesn't change the color of the vertical lines.

[rowbearto]

I'd prefer the vertical lines. Especially when the scope is too big to see on the screen and the matching curly braces are off screen.

[Graeme]

oh, ok, how about both colored vertical lines and colored background and a configuration option to select which. 

Also if the range of the block means it can't all be shown on one screen then a command to hide / unhide lines in the middle of the block  - or maybe a command that progressively hides/unhides more and more lines.

[mako]

Also if the range of the block means it can't all be shown on one screen then a command to hide / unhide lines in the middle of the block  - or maybe a command that progressively hides/unhides more and more lines.

The command hide-code-block will collapse the block that the cursor is in.


I think having an option to draw the vertical line connecting block start and end at the indentation level of the surrounding block would be much more useful than the current behavior of stacking them all up as far left as possible. As it is now, because my C++ code uses multi-level deep namespaces, the vertical lines are more of a distraction than an aid.

[jwiede]

Did this request ever receive any love?  I rely on it CONSTANTLY in VSCode & SublTxt, and while not the only reason, it's "one more cut" keeping me from using SE more often.

[rowbearto]

Yes it is now implemented in SlickEdit for a couple years now.

[jwiede]

I was away for much of v26, basically all of v27 and the beginning of v28, so apparently missed it, sorry, but really glad to hear it.

I'm trying to understand what the different "Outline" options actually indicate.  For example, does "statements" include lines between all matching blocks in C/C++?  I looked at the help docs, but they provided little additional detail in this regard.  Is there a table anywhere which shows what the different "outline" settings provide and don't provide?

That said, I'm not a huge fan of "modes" for this, as Outline uses now.  I would much prefer selecting which receive and which do not (which are lines vs background coloring, which can receive highlighting when cursor/ptr are in their "region", and which always remain dim regardless). 

I tend to believe modes always suffer from "a few sizes fit none", and wind up internally table-driven anyway.  Might as well save effort and expose the attributes table in the UX from the start, and just offer presets equivalent to the modes (but also allow users to define their own presets) -- all per-language ideally.

If SE can get that far, I'll even hold off for two versions before asking for "rainbow sequence assignments" for categories.