i am trying to convince the perl bundle to properly fold pod documents. has anyone tried this with success?
i have tried modifying the Start/Stop markers from
foldingStartMarker = '(/*|({|[|()\s*$)'; foldingStopMarker = '(*/|^\s*(}|]|)))';
to foldingStartMarker = '(/*|({|[|()\s*$|^=head\d)'; foldingStopMarker = '(*/|^\s*(}|]|))|^=cut)';
which works fine for a simple block:
=head1 HELLO
Hello, World.
=cut
but not for blocks that have more than one =head marker:
=head1 HELLO
Hello, World.
=head2 OOPS
Now head1 and head2 both show folding carets, but only the one one by head2 does anything when you click it.
=cut
i tried to get clever and use perlish zero-width positive look-ahead regex -- something like (^=head\d(.|\n)*(?==cut)) -- but textmate doesn't appear to support such patterns.
any suggestions?
On 7/7/2006, at 0:21, Michael Reece wrote:
i tried to get clever and use perlish zero-width positive look- ahead regex -- something like (^=head\d(.|\n)*(?==cut)) -- but textmate doesn't appear to support such patterns.
The pattern is only applied to a single line, so that’s why it won’t see =cut. However, both =head1 and =head2 would have seen =cut, if TM had given it the entire document.
As I see it, the only way is to decide which head level you want folding start markers, and ask explicitly for that, i.e. ^=head1$.
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.
thanks, michael.
On Jul 6, 2006, at 7:55 PM, Allan Odgaard wrote:
On 7/7/2006, at 0:21, Michael Reece wrote:
i tried to get clever and use perlish zero-width positive look- ahead regex -- something like (^=head\d(.|\n)*(?==cut)) -- but textmate doesn't appear to support such patterns.
The pattern is only applied to a single line, so that’s why it won’t see =cut. However, both =head1 and =head2 would have seen =cut, if TM had given it the entire document.
As I see it, the only way is to decide which head level you want folding start markers, and ask explicitly for that, i.e. ^=head1$.
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
--- michael reece :: software engineer :: mreece@vinq.com
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 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.
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
On 9/7/2006, at 20:02, Gerd Knops wrote:
[...] I would love to see a more powerful folding implementation, even if it means folding is only calculated during open/save of files.
I am all for more powerful foldings, but it seems your suggestion implies that folding logic was moved to a plug-in and only applied during load/save.
The big disadvantage of this is that most users can’t write plug-ins and moving to a code-based system (instead of the currently declarative approach) also makes supporting mixed document types infeasible.
Personally I am interested in semantic foldings [1] which speaks for integrating them with the language parser, where again moving them to plug-ins would be counterproductive for that.
[1] Realistically I will probably need 2-3 “modes” in which one of them was the semantic mode, as semantic foldings can’t handle all the user desires I am aware of.
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.
Ah, sorry. I thought the OP was writing his own code, not just browsing through the hundreds of thousands of third party code out there :p
On Jul 9, 2006, at 11:18 PM, Allan Odgaard wrote:
On 9/7/2006, at 20:02, Gerd Knops wrote:
[...] I would love to see a more powerful folding implementation, even if it means folding is only calculated during open/save of files.
I am all for more powerful foldings, but it seems your suggestion implies that folding logic was moved to a plug-in and only applied during load/save.
No, the 'only during load/save' remark was because you mentioned TM having to potentially look at the entire code for folding info would not scale. I'd rather have a more powerful folding implementation than real-time folding marker updates.
The big disadvantage of this is that most users can’t write plug- ins and moving to a code-based system (instead of the currently declarative approach) also makes supporting mixed document types infeasible.
Agreed.
Personally I am interested in semantic foldings [1] which speaks for integrating them with the language parser, where again moving them to plug-ins would be counterproductive for that.
[1] Realistically I will probably need 2-3 “modes” in which one of them was the semantic mode, as semantic foldings can’t handle all the user desires I am aware of.
I'd be happy with a language parser-like implementation, but it would have to get around the 'one line at a time' in order to gobble up empty lines, or opening braces on the next line etc. Also in some situations it would be handy to have a folding-start be also a folding stop.
Gerd
-
Allan Odgaard -
Gerd Knops -
Michael Reece