>> It would be wiser if you were a bit more subtle, since all of your accusations are actually your fault.

In actuallity its you who are mistaken...

>> The bracket-related problems you have probably occur because you use the literal characters ( and ) as parameters to $regex.

And how exactly would that be my fault when regular expressions CLEARLY state how to escape the special ( and ) characters with a backslash inside regular expressions and they are usable there as a grouping operator already?!? As I said, its a parsing error, but its still a bug in mirc. The fact that its possible to workaround it doesn't diminish this fact.

If you would try an example without assuming I did something idiotic like place d the literals ( and ) OUTSIDE of a regex like you did...

//var %a = ) | echo -s $regex(%a, /\)/)

This fails, and in fact any combination I gave above fails and ALL are valid regular expression syntaxes...


The location of the actual libary was a help though smile

Lifted directly from the library documentation:

Quote:
It is possible for an capturing subpattern number n+1 to
match some part of the subject when subpattern n has not
been used at all. For example, if the string "abc" is
matched against the pattern (a|(z))(bc) subpatterns 1 and 3
are matched, but 2 is not. When this happens, both offset
values corresponding to the unused subpattern are set to -1.

...
2. It sets up the subpattern as a capturing subpattern (as
defined above). When the whole pattern matches, that por-
tion of the subject string that matched the subpattern is
passed back to the caller via the ovector argument of
pcre_exec(). Opening parentheses are counted from left to
right (starting from 1) to obtain the numbers of the captur-
ing subpatterns.





Thus I stand by my BUG comment. This ALSO means that if you were to use the \DIGIT syntax (supported by the library) to refer to captured subpatterns you would immediately see the problem between the DEFINED positional syntax and the returned value of $regml() as I did...

-Yil