Hi,

This relates to the new bug report:
http://bugs.freepascal.org/view.php?id=13322

Code Folding seems to have gone way overboard! It simply makes the editor look like a mess at the moment (Lazarus svn trunk revision). What is the end goal of code folding? Maybe is in the middle of the overall goal and I am simply acting to quickly. Either way, I will voice my concerns...

In older versions of Lazarus the Code Folding [+] was in logical places. begin..end blocks. Now they appear on Implementation sections, uses classes, procedure/function level, begin..end block of procedure/function, begin..end block of if statements, var blocks etc... You end up with code looking as follows (code folding plusses everywhere)!

==============================
[+]implementation
[+]uses

      MyUnit1;

[+]procedure MyTest
[+]var

     x: integer;

[+]begin
[+] if x > 0 then begin
bla bla bal

      end;
    end;

==============================

I would much rather prefer a more sanely and less verbose code folding that does the following:

==============================
implementation
uses
   myUnit1;
[+]procedure MyTest
   var
     x: integer;
   begin
     if x > 0 then begin
        bla bla bal
      end;
    end;
==============================

At the moment it is more like trying to spot a line of code that doesn't have a [+] in the gutter!! This is just causing clutter and not actually adding any value as far as I can see. Especially now that the code folding lines and +/- signs are inside the editor code area and not the gutter area. OK, so we all know synedit now supports code folding, but we don't need it on every line. Maybe Lazarus should have a Code Folding verbosity level going from 'Normal Code Folding' to 'Insane Code Folding'.

This brings me to another point. Initially the Code Folding was not as verbose, so I tied the "Draw Code Divider" feature into the Code Folding feature. But now that Code Folding is so verbose it now makes no more sense and seems to get broken quite often. Maybe the "draw code divider" should become a separate feature and not tied into the code folding. The idea of "draw code divider" was simply to draw a horizontal line at the end of each procedure or method (like visual basic 6 did). I have no interest in drawing horizontal divider lines wherever code folding can occur. And with the current verbose level of code folding and horizontal lines (if they work) you will actually struggle to see your code between the whole mess.

Your thoughts?

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

There is a general plan/idea to add some configuration (have to see how much) to define what you want to have foldable and what not. It wasn't seen as urgent yet (at least not by me...)

Most (if not all) of the places that allow folding now, do so in Delphi as well. this is part of why they have been added, to make it easier for (ex-) Delphi users.

IMHO most of the new ones are reasonable?
- Except maybe for: "Program" / "Unit" and "Implementation" / "interface"; but they don't occur very often in a normal unit.
- Maybe discussable are "var" "Canost" "type" blocks? Think is they can be very useful for bigger "var" sections (but I agree they can be irritating with just on line in it)
- Folding at class / private / public => IMHO should be ok?
- Folding at "procedure" in addition to the begin => arguable, if it should be instead of the begin?

Will be interested to see, if other people will voice opinions, which of the new foldings they like, which not....

.....

You can change this:
The gutter divider line is moveable, and the code fold background color adjustable.
Only the code-folding is now on the right side of the gutter (towards the text) rather than the left, as it used to be.

Enviroment=>options=>editor=>display=> "gutter separator index" Enviroment=>options=>editor=>color=> "code folding tree" (3rd in box)

That can be looked at / I can see the benefit of such a feature.

Not sure where it gets broken? Are the pictures from different versions of lazarus? or are they with different settings?

If you want then at begin/end level you need to set the divider draw level higher => the down side is, there will be additional dividers. This may not be the effect you desire, but it is the effect intended.

Best Regards
Martin

OK thanks. So configuration is in the pipeline - that is good to know. :)

Most (if not all) of the places that allow folding now, do so in Delphi as well. this is part of why they have been added, to make it easier for (ex-) Delphi users.

I did not know that. I last used Delphi 7 which had no code folding. I've only seen code folding in other editors and they were not that verbose as the current synedit in Lazarus. This is why I thought I would mention it.

IMHO most of the new ones are reasonable? - Except maybe for: "Program" / "Unit" and "Implementation" / "interface"; but they don't occur very often in a normal unit.

I don't see the point of 'Program' or 'Unit' level. Many the others could be useful.

- Folding at "procedure" in addition to the begin => arguable, if it should be instead of the begin?

I'm not sure about this one either. I would have thought the first 'begin' after a procedure or function should be ok.

I know the gutter divider line is movable, but I didn't know the background color is adjustable. I'll give this another try. See the original bug report for my editor colour scheme - it's not quite standard colours which probably exaggerated the problem a bit. ;-)

Enviroment=>options=>editor=>color=> "code folding tree" (3rd in box)

Thanks, this makes code folding look a lot better already. My gutter is a different colour to the editor background. Now the code folding tree blends in much better with the gutter part.

Before horizontal line drawing between procedures / functions, I have seen programmers add spaces to separate methods. Or use comments as dividers. eg: {-------------------------------}

Those are all waisted efforts and get in the way of coding and programs such as 'pasdoc'. The visual effect of synedit drawing the line (without anything actually being in the source code) is brilliant and gives a much better look!

I think it will be worth having as a separate feature to code folding. And at the moment I can only see it being useful between procedures, functions and methods. I would ignore nested methods for now - it can be added at a later date if the need arises.

Not sure where it gets broken? Are the pictures from different versions of lazarus? or are they with different settings?

Nope, the screenshots in the bug report is all taken using the same project, settings and Lazarus version. I simply switched tabs and took screenshots.

If you want then at begin/end level you need to set the divider draw level higher => the down side is, there will be additional dividers. This may not be the effect you desire, but it is the effect intended.

I think my original idea or method dividers got lost somewhere. :-) I only indented the feature to have dividers between procedures, functions and methods. No nested methods and no other code folding areas.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

If you set the draw level to 3 or maybe 4, you should get the correct divider draw levels.
You will have to ignore the dividers drawn at the end of implementation sections....

so they are all with
"Settings:
Code Folding: Enabled
Divider Draw Level: 1
"
?

In that case the first picture is wrong => with DDL=1 there should be no line between procedures (it would be at the end of the unit level.) Not sure if complete:
DDL 1: unit level
DDL 2: implementation/ interface
DDL 3: Procedure implementation / class declaration

since you only switched tabs => did you aybe change config in your session? maybe the issue was that the config change was not set to all editors?

try level 3.

Best Regards
Martin

Yes

ah, nice to actually know what each level means. :-) Maybe that should be place in the options screen instead of just numbers.

since you only switched tabs => did you aybe change config in your session? maybe the issue was that the config change was not set to all editors?

That seems to be the partial cause. Setting the level to 3 gives the most desirable outcome I wanted. But only after I restarted Lazarus, did all the editors update. So there is one bug - not all editors get updated.

I then played with the levels to see how they differ. After changing the level, i did a Lazarus restart. It seems at Level = 2, I again get the same behaviour as the bug report. Even with a restart. So that seems to be another bug.

try level 3.

Yes, that gives the best results for me.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Is it possible have folding or more specifically identification for case/end pairs?

Actually, at least in Delphi 2007 code folding works only down to classes and procedures, not below. Still, I think it is a good feature.

I'd say that such deep nesting should have very detailed configuration. I suggest to replace current numeric setting with a grid of checkboxes controlling code folding and divider drawing separately at logical levels:

Level | Folding | Divider
Unit/Program | Off | Off
Section (interface/implementation/...) | On | Off
Class/Object/Record Type Definition | On | On
Class Visibility Specifier (public/private/...) | Off | Off Other Type Definition | On | Off
Uses statement | On | Off
Global var/property/const | On | On
Procedure/Function/Method implementation | On | On Nested Procedure/Function | On | Off
Local var/const | Off | Off
Begin/end blocks | Off | Off

Additionally, maybe for begin/end blocks a separate setting to turn folding on for blocks longer that N lines.
The settings I above are my preferences, and I hope also reasonable defaults.

In a "program" it differs from a "unit", because you do not have the implementation/interface section.
Include files may differ again.

Those differences were always present, even with the older folding. The level only represents how many nested folds you have

Unit: is the top level fold; not nested
implementation/ interface: is nested in the unit fold procedures are nested into the implantation fold
......

Ok, I will check this part: "proper propagation of config changes, with regards to divider fold level"

Are all 3 files units? with unit keyword at the start, and implementation/interface sections....
if you have an include file, with no "unit", no "interface" / "implementation" => then "procedure" is the top level fold (divider level = 1)

I will need some feedback to reproduce this.

Or if the behaviour is due to differences in the nesting structure, then the bug breaks down into:
- propagation (see above)
- restore the old behaviour that "procedure" divider lines, can be drawn independent of the fold-nest level.
(they used to be top level, which is why they used to be content independent => that has changed)

Best Regards
Martin

Not yet.
this will at earliest be implemented, when individual folds can be configured. The same applies for repeat/until
It may also have to wait fro some more/other refactoring on the folding.

The highlighting currently depends on the detection for folding.

So it will be a while till that is done.

The problem is that there are already units, that take more than one second to parse, and that can behave sluggish if you insert words like "begin". So implementing this must be done with care. If you have an idea how to patch this, please feel free to discuss.

Best Regards
Martin

I thought about it too when I composed the list in the previous message, but considered them overkill. If single-statement folds, like for 'case', 'with', 'if' etc.
will be implemented, they should be able to "merge" with begin/end folds for their bodies, to avoid useless almost-duplicate folds.

As long as it can be switched off, you won't hear me complaining :-)

Michael.

The next logical step is unfolding include directives, so that the included files can be inlined in the editor. This is what Delphi users will need urgently, and every user will appreciate the capability of searching and find-and-replace in the entire resulting text.

DoDi

Procedures can have large parameter lists, type, var and const sections, in addition to the code body. When a procedure is of no (visual) interest, all that should go out of the should recognize two tree structures:
1) sequential sections, like case labels or above type/var sections
2) nested blocks, like arbitrary begin/end pairs

Type 1 sections only have an "label", and extend until the next sibling.

Type 2 blocks have both head and tail delimiters.

DoDi

Martin Friebe wrote

> In a "program" it differs from a "unit", because you do not have the implementation/interface section. Include files may differ again.

OK, thanks...

OK, this might have something to do with it. The file 'calendartest.lpr' is a 'program' file. The other two are standard 'unit' files. This probably explains what I saw. The 'program' file is handled differently even though I was looking at methods of a class. Two files had an implementation section and one didn't.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Hans-Peter Diettrich wrote

will need urgently, and every user will appreciate the capability of searching and find-and-replace in the entire resulting text.

I was thinking about 'find' and 'find-and-replace' to work for include files as well, but I could get my head around a solution. Think about FPC code where includes are based on platforms. You have the same include name, but different implementations depending on the platform. How do you inline something like that, or search across such includes? You can't expect a search-and-replace, only finding include files for one platform, but ignoring the other 14 supported platforms. :-(

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

I was thinking about 'find' and 'find-and-replace' to work for include files as well, but I could get my head around a solution. Think about FPC code where includes are based on platforms.

Yes, I know that. This practice is almost the only argument for using include files at all.

You have the same include name, but different implementations depending on the platform. How do you inline something like that, or search across such includes?

Exactly as the IDE does it, in the navigation between a class definition and method implementation.

DoDi

OK, but my point is as follows... Say you have a common interface section and 15 different implementation sections using include files. Now under Windows you do a search-and-replace which changes the interface section and 1 out of 15 possible include files. That means your have 14 other include files still remaining with the old identifier names. This is definitely not ideal - hence why I said I have not found a solution for this yet.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

An important feature and not only to ex Delphians, would be nice to see the content of include files within the main source file possibly with a slightly different background so it shows that the content is not really inside the main file, as an extra feature it would be interesting to allow the user to select from the list of available includes on all platforms, if he wants to alter code in more than one file, usually the programmer only needs to see the include file for his current platform. As for multiple platforms, you still need to at least compile and briefly test the compiled application on all platforms, so the switching feature is not as important, one can still edit those includes separately.

Razvan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20090318/0ec95d71/attachment.html

Configuration has now been added. So you can fine tune which element you like to be able to fold, and which elements you don't.

Best Regards
Martin

Martin Friebe wrote

Configuration has now been added. So you can fine tune which element you like to be able to fold, and which elements you don't.

I played with it, and it generally works very well, thanks ;-)

Some minor issues:
1) When 'Code folding' is unchecked, other controls should probably be disabled. Also, 'Enable code folding' is IMO a better name.
2) Language dropdown should probably have a label.
3) 'Folding'/'Divider' buttons are slightly confusing. Maybe it is better to make common list
of language constructs with additional 'Fold' checkbox, and make it visible only when needed?
Alternatively, how about at least using PageControl instead of two buttons?
4) Some combinations result in two dividers drawn separated by and empty line (e.g. after the last procedure and before the initialization section). IMHO in such cases
only one divider should be drawn.

True, but that will be a lot easier, if folding and dividers are more separated (see item 3)

Dividers need a global switch too.

2) Language dropdown should probably have a label.

Hm, yes, "sugar" as far as I am concerned. But easy if the 2 buttons disappear (so it will be done together with the item 3)

I don't like the page control to much, I tried it.... The more likely solution (and feedback shows it will be needed) is to have 2 complete independent pages in the tree on the left.

Patches are welcome, I have some other stuff that I currently prioritise at a higher level

Hm yes and no.

This happens with var/type and unit-sections. The reason: Those end before the next section, potentially including empty lines at their end.
All others end before the empty lines.
So they can be separated by any amount of empty lines

Simple drop them would not work for people who have them in different colors (ok ,I do not honestly believe this is an issue)

An other way, would be not to determine if we already drawn some other divider, but instead to end those blocks always in front of any empty lines (as long as those empty lines are at the end of this block). It would however mean that (if differently colored) the end of a type-block is drawn over the end of a class-block, hiding the end of the class

I am not yet sure, If, when or which way I will do that.

Best Regards
Martin

Sorry, no patch from me, but I can create an issue if you want. I have no problems with a separate page,
but why do you reject a common list? It seems the best solution to me.

> 4) Some combinations result in two dividers drawn separated by and empty line > (e.g. after the last procedure and before the initialization section). > IMHO in such cases > only one divider should be drawn

[skip]

Simple drop them would not work for people who have them in different colors (ok ,I do not honestly believe this is an issue)

BTW, don't you think that per-type divider coloring is an overkill? Perhaps a single color on Colors page would be sufficient?

These are minor things, nothing to worry about too much.

Alexander Klenin wrote

BTW, don't you think that per-type divider coloring is an overkill? Perhaps a single color on Colors page would be sufficient?

I think it's pretty neat. And if you don't want it, simply don't use it. By default all divider lines are the same color anyway.

I think the dividers, code folding and code tools settings are excellent at the moment. It's the first time in 4 years since I started using Lazarus that I can finally setup the editor exactly the way I want. Big thumbs up from my side - thanks to all that put in the effort.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Dividers initially could only be set at places where a fold ended. Now they can be set at places, even if the place is not configured as the end of a fold. So they are a separate feature.

Divider-Locations also is a different list than Fold-Locations, so sharing the same list, would be confusing.

Not necessarily.
For Example (I use this) I have a normal grey (same as right/80-column border) for procedures ( I use a lighter grey for nested procedures. So I can see the difference between nested and top level procs.

Also I plan further extension which will make the colors more useful. Have to find the link again, I had it in a previous mail about the topic.

Martin

Martin Friebe wrote

For Example (I use this) I have a normal grey (same as right/80-column border) for procedures (procedures at top-level. But I use a lighter grey for nested procedures. So I can see the difference between nested and top level procs.

Exactly what I am doing as well. :-)

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Well, there are already two divider sub-kinds -- nested and normal ones. They already display different controls (spin editor vs checkbox, second color picker).
I suggest to add 'Fold' checkbox, in the same vein -- it will be displayed only for foldable locations.

No problem, but how do I globally change divider color then? Do I have to change it for every kind of location?

As I said there may be more oprtions in future, so better to keep them separated

Leave them on default, and change the color of the "right margin" / " 80 char" indicator.
They always used to follow the color of that, they still do.

For all else, it would be cool to make the listbox multi-select => but that's a lot more work....

Anyway, thanks for the feedback, it goes into collected thought, until I decide to do something about it....

Best Regards
Martin