I think David's on to something good here. A major problem with holding the bracket-matching possibilities in a special variable (or a pair of them) is that one can't figure out what the RE is going to do just by looking at it -- you have to look elsewhere. Nathan Wiger wrote: >I think it's cool too, I don't like the @^g and ^@G either. But I worry >about the double-meaning of the []'s in your solution, and the fact that >these: > > /\m[...]...\M/; > /\d[...]...\D/; > >Will work so differently. Yes. Things that look similar should act similar. Things that act differently should look different. >But, how about a new ?m operator? > > /(?m<<|[).*?(?M>>|])/; > >Then the ?M matches pairs with the previous ?m, if there was one that >was matched. The | character separates or'ed sets consistent with other >regex patterns. Ah, this is a neat idea! Unfortunately, as Richard Proctor pointed out, ?m is taken. Perhaps (?[list|of|openers) and (?]list|of|closers) ? Does that look too bizarre, with the lone square bracket in each? Or does that serve to make it mnemonic (which is my intention)? And --- can-of-worms time --- we're only intending the list elements to be constant characters, but that syntax *looks* like it can take a regular expression for any of the list elements, so people are going to try to do that someday. I cannot imagine what someone would want do use a regexp in such a construct, but abuses of the language are not limited to *my* imagination :-) (?[list|of|openers) would match any expression in the alternation list. Subsequently, (?]list|of|closers) would match the *corresponding* expression, but would keep track of the nesting level of the originally- matching open-bracket expression. Sound about right? ---------------------------------------------------------------------- Eric J. Roode, eric@myxa.com print scalar reverse sort Senior Software Engineer 'tona ', 'reh', 'ekca', 'lre', Myxa Corporation '.r', 'h ', 'uj', 'p ', 'ts';