Been messing with $regex and its children recently, and I discovered a couple of 'issues' with them, specifically $regsub.
Summary- %var parameter of $regsub should be optional
- $regsub should handle $identifiers/expressions in 'subtext'
Issue #1First and foremost, (out of sheer personal preference) I find that the interface for $regsub is a bit awkward to use.
$regsub([name], text, re, subtext, %var)
Note that the last parameter is a %var. To me this is slightly awkward, in the sense that i feel that $regsub should be able to be used inline, just like $replace would (since thats what it is). I dont think that you should be setting a variable, rather $regsub should return the modified string directly.
Now I know that $regsub (currently) returns some very valuable information, specifically, the number of matches detected, but generally this information is kind of useless when it comes to a replace function, and not a matching one.
Obviously the fourth parameter should
not be TAKEN OUT (for those who want to use it to return matches) but i believe that the fourth parameter should be optional, and if not given, $regsub will return the modified string, so it can be used inline. Moreover, if its possible (and not to stressing on Khaled's coding time), a $regn should be added to return the number of matches to the last $regsub() call [the same way $readn returns the line matched in the last $read() call].
An 'almost perfect' workaround:A clear and simple workaround to making the fourth param optional would be:
replacere {
var %x, %r = $regsub($1, $2, $3, %x)
return %x
}
The problem with this alias however will be answered in my
Issue #2Issue #2Glad you could make it this far... I tend to write a lot. This one will be slightly shorter, hopefully... Anyway, $regsub has another limitation which doesnt allow it to evaluate expressions within the
subtext parameter (param #3) of the $regsub call. I tried every way I could think of to get it to evaluate but just couldn't. evaluating expressions in that parameter can be very useful.
For example:Sum the numbers in the string: 1 2
One solution would be: (I use $replacere for inline regsubbing)
//echo -a $calc($replacere(1 2, /(\d+) (\d+)/, \1 + \2))
The problem with putting $calc outside lies in the simple idea of
greedy matching. If i were to try this example:
Sum each set of 2 numbers in the list: 1 2 3 4
(I want to return 1+2 and 3+4, or 3 and 7)
//echo -a $calc($replacere(1 2, /(\d+) (\d+)/g, \1 + \2))
The above code would try to $calc(1 + 2 3 + 4), which of course is errant.
Workaround #2, with a limitationUpdating my $replacere alias, I get:
replacere {
var %x, %r
if ($4 == e) {
%r = $regsub($1, $2, $replace($3, $chr(36), ÿ), %x)
return $eval($replace(%x, ÿ, $chr(36)), 2)
}
else {
%r = $regsub($1, $2, $3, %x)
return %x
}
}
This new alias has an optional 4th parameter which takes 'e', and will replace all identifiers $ with ÿ so that mIRC doesn't try to evaluate them inside (because it will fail if it does). After it regsubs it turns the ÿ's back to $'s and $eval()'s
Obvious limitation to this code, of course, is the unpredictable results if I were to use ÿ in a subtext string (of course the 'e' parameter combats that limitation, but only to an extent).
-----------------------
ConclusionOkay, I laid out all the information I gathered. Basically what I'm trying to say is, there is no foolproof way to implement a workaround for $regsub that supports evaluating identifiers in the subtext parameter, so it would be nice to see that feature added.. And if the $regsub identifier was to be reworked, might as well make that 4th parameter optional to allow for inline usage.
There, I'm done. Thanks for reading.
