Code folding tree — highlighting current foldable block

[furious programming]

I have it set in the IDE settings to always color the folding tree in gray (same color for different tree states), see the first attachment. I would like the tree to be colored white, but only for the code block that caret is inside (and all nested blocks), see the second attachment. Can this be set somehow? I looked for suitable options, but found nothing.

By the way, I think it would be nice if, in addition to the folding tree itself, you could also define the color of the line numbers for the active block — see the third attachment. But for now, it would be enough for me if the folding tree could be highlighted.

[Martin_fr]

No, there is on such option at current.

You probably know: https://wiki.lazarus.freepascal.org/New_IDE_features_since#Outline_for_Pascal_Sources
But it is all blocks, all the time.
You can configure the colors, use dotted lines, only use the lines, and don't change the keyword, ....

You can add a feature request for the gutter.

The fold gutter has it's own unit => so code is easy to find. In case you want to look yourself.


Unfortunately that means, line numbers are in a separate unit, in their own class. And they have no idea folding even exists. So that is a bit harder to add.

[furious programming]

You probably know: https://wiki.lazarus.freepascal.org/New_IDE_features_since#Outline_for_Pascal_Sources
But it is all blocks, all the time.

Yes, I know this, but — as you wrote — it is intended for all blocks.

You can add a feature request for the gutter.

I briefly looked through the SynEdit code, but there is so much of it that it would take a million years to find anything appropriate, so I just have to create a feature request. I'm not familiar with the code for this control, and it's quite complex, so it's best if someone who knows its implementation will take care of it.

As for me, I need something that will somehow help me point out the block where the caret is located. I think that highlighting the block in a different style for the folding tree will be sufficient. I think it would be good to be able to choose (checkbox) whether the highlighting should apply only to the current block (in which the caret is located) or also to all nested blocks. See the first and second attachment. I would probably use highlighting only the current block (second attachment) to better understand what level of nesting the instructions I am modifying are at.

[Martin_fr]

Units SynGutterCodeFolding and SynGutterLineNumber,

Both can access SynEdit.CaretY => so you know where the caret is. (doesn't handle multi caret)

Also they get SynEdit.Highlighter

If 
  SynEdit.Highlighter is TSynCustomFoldHighlighter
then

try getting FoldBlockMinLevel (atype = 0) for the current caret line

Then go up/down, and as long as the FoldBlockMinLevel does not go below what it was in the caret line....


May need some fine tuning. But generally that should do...

atype 1/2 are ifdef and region (if avail / FoldTypeCount > 1)
in the pas hl

FoldBlockEndLevel
  level at the end of the line => e.g. if a line has BEGIN then that is included, but also if it has END.
  So  a line with END will have a count lower than you want, but  FoldBlockEndLevel is also the level at the START of the next line. So use that.

FoldBlockMinLevel
       end else begin
  The FoldBlockMinLevel shows you that the line closed stuff, even if it then opens them again.

So with using both of them you should be able to get it right.

[Martin_fr]

Done in 3.99.

Small "curiosity"...

Code: Pascal  [Select][+][-]

1. type tfoo = class
2.   private
3.   a: integer;
4.   public
5. end;
6. ...
7. procedure bar;
8.   var
9.     a: integer;
10.   begin
11.   ...
12.  

The "private" and the "var" block are closed by the "public" and "begin".

Technically the spaces at the start of the line, are part of those 2 blocks. But in order to have a nice fold-tree in the gutter, the blocks ends are moved to the line before the closing keyword (because that closing keyword (usually) opens a new block, and having close and open overlap into the same line does not look pretty.

As a result those leading spaces are not part of the "private" / "var" block. But also not of the next block. They are attributed to the enclosing block (class/procedure) and highlighted accordingly.

This does not happen if there are non-spaces on the closing line before the "public" and "begin".

Of course the attribution could be improved. This was simply the easiest way. And for now, this is "by design".

Code: Pascal  [Select][+][-]

1. procedure foo;
2. begin
3.   ...
4.   if a then begin
5.     ...
6.   end else begin
7.     ...
8.   end;
9.   ...
10. end;

Here the highlighted block works correct.
- up to and including the "end", the block above is highlighted
- on the "else" it is in neither of the "then" nor "else"s begin/end. => the procedures begin/end is active
- after and on the "begin", the block below is highlighted

[furious programming]

Can you show some screenshots with this feature in action?

[Martin_fr]

If you are on line 281 then the caret x pos matters. Anything in front of the "begin" (the block starts with the "begin" / "if" does not have folding) will highlight the begin/end of the function.

Obviously (hopefully) if you wrap the statement and have the begin on the next line, the fold begins on that next line (as it always has done)

I have plenty of other colors, that are unrelated (but I didn't change my settings just to make a screenshot)

[furious programming]

Looks great! Is the style applied only to the current block or also to all nested blocks in it?

I see that your version of Lazarus have many additional styles possible to set, that are not yes in the official release. I like it — the more styles available to set, the better for the user.

[Martin_fr]

It is also set for all nested blocks.

The only other feature not in 3.2 that is in my screenshot is the "current line in gutter".
Not in 3.2, but also not the picture: color for modifiers like virtual, overwrite, deprecated, cdecl...

The grey background is "current word"
The pink text is "procedure name"
And the blue background is a "user defined markup", a color that I set per keypress to a word of my choosing, so I would easily spot it.