Great. In the second thread I linked to, we were two to mention that the help file was a bit wrong, looking at the help file now it's still the same, could you edit some phrasing?:
$regex([name], text, pattern)
[quote]You can assign a name to a $regex() call which you can use later in $regml() to retrieve the list of matches.
I have been suggesting a lot that mIRC's regex implementation doesn't offer us the actual matches (aka full matches), mIRC only offers captured groups, I would really love to see full match available, and it's only about returning the positions of the actual matches, which are returned by PCRE. In any case here it says that $regml retrieves the list of matches but it retrieves the list of captured groups, not matches.
$regml([name], N, [&binvar])
This returns the Nth match returned by a call to $regex(), $regsub(), or $regsubex().
Same as above, $regml returns captured groups, not matches
$regmlex([name], M, N, [&binvar])
If the /g modifier is used with a pattern, multiple results can be returned for that pattern. This identifier allows you to retrieve these results, where M is the Mth result and N is the () capture group number in that result. If N is not specified, it defaults to 1.
It is not necessary for /g to be used to have multiple captured groups, the beginning suggesting that $regmlex can only be used with /g which is not true. And "results" should really be renamed to "matches" (.match property is correctly saying 'match number' not 'results' or anything), M is the Mth match number.
F - make back-references refer to () capture groups, which is how standard regex works.
It should say something like "F - Include non-participating capturing groups in the list of captured groups, which mIRC ignores by default.
while
Note: If the F modifier is not used, \N references in patterns and N indexes in identifiers refer to the order in which matches are found, and $regml() will not include empty matches.
should really just be removed, because /F has nothing to do with \N reference in the pattern, and it's not about N indexes in identifier referring to the order of which matches are found, and empty groups (not matches) are different from non participating group.
By the way, I've said in previous thread that I wasn't sure if knowing if a group participated in the match was 'important' or not, but it is, because with /F now, empty captured and non participating groups are both returning $null, $regml().pos can be used to tell, returning 0 for non participating groups.
-
