Um, if we had single-character delimiters, then the suggestion in Death to Dot Star would apply; use a negated character class in place of "dot":

    m# \[ [^\]]* \] #x
[download]

If you are wanting me to do that complex trick to avoid matching a closing (or even opening) delimiter in the middle, then I don't think you read the thread. Lots of good people tried and failed to get it right. I don't recommend doing that trick since I've never seen it proposed (even by amazing people) without someone finding an error in it.

Plus, it wouldn't gain us anything in this case. If I see an opening delimiter in this situation, I want to force the match to start there. It would be an error to have extra, unmatch starting delimiters. We aren't trying to parse English here.

As for matching nested blocks, that pretty much violates the original design. For defensive programming, I'd probably have the expand() routine look for and warn of opening delimiters in the match string since these might indicate that a closing delimiter was dropped or munged. But to be completely defensive would require more work than that.

Well understandably the paranethesis matching of this is extremely difficult. It's my intuition that regex isn't the right solution-- reformulating the problem is. :) At the very least, you could just rip out all []s and get back to single character pairing with nesting. What strikes me as odd is why the data would even be in that format to begin with... Surely you could come up with a more meaningful output format...

-Ted

sub parse {
if ( $_[0] =~ /\[(.*)$/ ) { parse($1)}
else {
if ($_[0] =~ /(.*)\]/ ) {
#Do your replace on $1
}else{
die "Unmatched brackets found";
}
}
}
[download]

or something like that anyway. But you probably wouldn't want nested brackets in a template system.

____________________
Jeremy

But you probably wouldn't want nested brackets in a template system.
I would =P

UPDATE: Geez I was just trying to be goofy and now I have to justify this ;P

OK, if you are just expressing basic values with your template system, you don't need nesting. If you are just enclosing code in another language you don't need nesting. If, however, you wish your template engine could do some light-weight decisions without having to resort to heavy code you might like having blocks like this:

[? variable_that_might_exist ?]
  HTML that uses the array that 
  [$ variable_that_might_exist $]
  flags the existence of...
  [@ maybe_array @]
[/ variable_that_might_exist /]
[download]

Worse, you may wish to emulate a light-weight version of a hash in template code like:

[% hash_name -> [$ key_1 $] %]
[download]

Sure it's stupid and there might be better ways but I have done something like it before (when I invented my own template system 4 years ago, where-o-where was Text::Template then?) and found that it was MUCH easier and safer to give my HTML people a seriously lightweight but "codeable" template system verses a glorified s/\[\$([a-zA-Z0-9_.-]+)\$\]/$hash{$1}/g system.

Tho there is no shame in that system =)

--
$you = new YOU;
honk() if $you->love(perl)