Hmm... Well, first off you've convinced that mirc is parsing the regular expressions more like normal scripts than I had originally thought. It turns out that examining my code I don't use spaces anywhere in my regular expressions but instead use the whitespace identifiers and thus all my %'s, []'s, etc aren't evaluated because they aren't space separated so I never saw any of them do anything... The fact that ()'s don't need spaces around them is why I only saw them as a problem. I also foolishly thought /%temp/ and / %temp / would evaluate the variable if it were going to work when I quickly tested this before posting. It turns out the second was evaluated but kept the spaces and thus failed to match! Doh...
Since mIRC doesn't seem to be special caseing the / / syntax as I had orginally supposed this might be catagorized as an "undocumented feature" and not a bug. In this case it should be noted in the helpfile that the /expression/ is still evaluated instead of treated as a literal string as in everything else I've ever used like perl, emacs, awk, etc...
My solution will be to never inline anything ever again in the $regex call... I'll set a variable to the expression I want and then use that because at least thats consistent... Not sure what I'll do about postfix operators yet but I guess I'll figure it out with some simple $+'s hehe...
As far as the rest goes... Its NOT valid to propose I solve my subexpression issue by use a NON-GROUPING operator like ($?:). I admire your persistence in changing the meaning of my regular expression time and time again to something that sidesteps the $regml bug but you are completely ignoring the fact that I wish to test whether a subexpression matched by examining $regml(). Your solution expressly forbids this! Perhaps I haven't been clear on this because I certainly know how to use non-grouping operators...
However, I think this difference between \3 and $regml(3) is intentional: mirc doesn't fill $regml(N) in some tricky way, it just receives pointers from PCRE. If you think this is a bug (I don't), blame PCRE.
I can't blame PCRE because if you scroll back you will see that I cut and pasted the actual documentation from the PRCR man page where it indicates it returns empty results as placeholders for unmatched subexpressions because not all of them will match. mIRC is handling the returned result incorrectly by not preserving them. Period. The way it currently works even the use of a single operator like ? makes $regml absolutely meaningless for any later subexpression testing. Its a bug...
-Yil
