Why o Why don't you use Text::Template or one of the 263 other template modules on CPAN? Do you think the World need another template system?
Seriously, you will start with a simple template mechanism, then you will add function support, then something else, then one more feature... and before you know it you have built a package with most of the features of the CPAN ones, just in a much more clunky way and without their robustness.

Please do yourself a favor and use a module!

I don't think Text::Template will do what this guy wants. With Text::Template you can make the delimiters anything you want, but you can't have more than one set of delimiters. So you could have [(...)] or [|...|], but not both.

And actually, I only know of 29 template modules. Are you sure there are 263?

s#
    \[ (  \( .*? \)
        | \| .*? \|
        | \{ .*? \}
       )
    \]
# expand( substr($1,0,1), substr($1,1,-1) ) #gex;
[download]

Haven't you read Death to Dot Star yet? You will have much trouble matching something like [{ [{ }] }]

-Ted

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]

but that isn't the case here.

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.

        - tye (but my friends call me "Tye")

In the event that you did have nested tags, you would probably want to go for a recursive function. Something like:

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