I'm trying to work out a couple of bugs in my XML syntax. I may have uncovered a bug in the folding code, or I may just be suffering from regexp brainfade...
What I was originally trying to accomplish was two types of folding. I wanted the following to fold up: (begin) <foo> <bar /> (end) </foo>
... and I also wanted this to fold: (begin) <foo key="value" (end) key1="value" />
The latter would ideally fold to <foo key="value"(...)
Am I correct in believing that this second form can't be accomplished with the simple folding marker regexps available now? The help doc says that it expects the end folding marker to be on the same indent level as the start folding marker, and the second form definitely is not.
Now, for the part that may be a bug:
I haven't found a regexp that will make TM *ignore* the abbreviated (but multi-line) XML element above (the 2nd one). Perhaps this is all well and good, except that TM seems to rather arbitrarily match the would-be end tag for the shortened element. I'll annotate the screenshot below:
Line 62 starts one of those singleton elements. Note that there is no closing tag, but at line 67, another element begins as the same indent level. In the current state, if I use the folding start button in the gutter at line 62, TM folds the document to line 72 (the end of the first </target> text). If I fold the "clean" target (lines 67 to 71) and then fold the <target> at line 62, TM folds all the way to line 92.
It seems to me that TM should stop searching for a match if a new start fold marker is discovered at the same indent level. Is that correct, or are my regexps just more sloppy than I thought they were? :-)
On 9. Oct 2004, at 4:51, Brian Lalor wrote:
I haven't found a regexp that will make TM *ignore* the abbreviated (but multi-line) XML element above (the 2nd one). [...]
Currently all matching is done on a single line at a time.
I'll keep this limitation in mind when I refine the folding system.
Kind regards Allan