On Jul 7, 2006, at 10:23 PM, Allan Odgaard wrote:
On 8/7/2006, at 0:04, Michael Reece wrote:
some sections begin with =head1, some with =head2, some have both =head1 and =head2; but all end with =cut.
so there is no way to come up with folding patterns that will intelligently fold POD sections? can't have everything, i guess.
No -- for what you want you need to look at lines both above and below the current line to decide if the line is a folding marker. If TM did that, it would mean that editing a single line would in worst-case have to look at every other line in the document. That doesn’t scale.
I would love to see folding reworked. Not sure how others use folding, but I almost never use it to just fold a block, I only use it for entire methods/functions/subroutines/whatever. Preferably I would code to open with just top level comments and method/function/ subroutine/whatever definitions visible, no extra lines. That speeds up code navigation tremendously.
Currently folding can't do that:
- It forces me to put the opening brace on the same line as the method definition, or I end up with a line containing just the opening brace and the fold marker
- It can not gobble up trailing empty lines
- It can't deal with situations like the one described above.
I would love to see a more powerful folding implementation, even if it means folding is only calculated during open/save of files. As is, I don't use folding much and really miss it.
I don’t know how much freedom you have with the POD markers, but you could introduce a convention, e.g. trailing space after =head2 makes it not a fold marker. That would then allow you to manually exclude the problematic folding markers.
There are tens if not hundreds of thousands of perl files containing POD documentation, so this is impractical. Never mind that making an invisible trailing space do something is just a bad idea in the first place.
Gerd