Forums Feature Suggestions About regexes and if statements

I would like to suggest some features for mirc; since they are a bit related, I will keep they in the same topic. They aren't really necessary, but will be useful in some circumstances.

1. case-insensitive regex

i would like a .nocase or .ci (case insensitive) property or anything like this in $regex and $regsub, for insensitive casing of regex. i use an alias like this:

alias regex-nocase {
return $regex($lower($1),$lower($2))
}

but i think that is too simple create the .nocase

2. isregex and isregexci operators in an if statement (and while and etc)

like iswm, an isregex would be a great feature to make the scripting more productive.

instead of do an if ($regex($1,^text.$)), is better do an if (^text.$ isregex $1), because it's far more simple and readable

the isregexci would be an case insentive version; and would be an !isregex and !isregexci as well

3. personalized if operators

suppose that i have a bot that verify if a number is prime or not and i use this alias:

alias isprime {
if ($1 !isnum 2-) || ($1 != $int($1)) return

var %x = 1

while (%x < $int($sqrt($1))) {
inc %x
if (%x // $1) return
}

return $true
}


it would be far more readable use this event:

on *:text:*:#:{
if ($1 == !verify) {
if ($2 == null) {
msg # Sintax: !verify [number]
}
elseif ($2 isprime) {
msg # $2 is a prime.
}
else {
msg # $2 is not a prime.
}
}
}

instead of use this:

on *:text:*:#:{
if ($1 == !verify) {
if ($2 == null) {
msg # Sintax: !verify [number]
}
elseif ($isprime($2)) {
msg # $2 is a prime.
}
else {
msg # $2 is not a prime.
}
}
}

1. Case insensitivity already exists using the i modifier, the same as regex works in all PCRE implementations (that I'm aware of).
ie.
A case insensitive version of $regex(mOo, [color:blue]/o/)[/color] would be $regex(mOo, [color:blue]/o/i)[/color].

ah, ok, that is interesting. the help file that i use do not describe any modifier. *sight* :-(

Point 2 seems redundant and confusing.. and I don't really see the point in point 3..

1.
possible switches are: igSmxUs
The S means strip color codes (like using $strip($1-) as input text), the others are pcre switches. Best suggestion is to read http://www.pcre.org/pcre.txt a few times, there's useful regex info in there (somewhere).

The pcre switches (not the S) can even be set using (?i) and unset using (?-i)

2. Might be helpful to use {1,4} constructs, which would need some $chr(44) work in a $regex(). Ofcourse only an isre, no case sensitive versions...
(While we're at it, why no %var =~ /regex/ ? )

3. Can have it's uses, is asked before (a lot), problem is the alternative is too easy to do any work for it

Redundant and confusing? Maybe it's my bad english I don't know really when I type something correctly in english or not. I am sorry about this.

But I will try to explain: Many times I do not use regex because is far more simple use wildmatch. It's only due the fact that wm uses an if comparison and regex uses a ident. I try to make my code "clean", and using $regex in the if statements don't help this.

And, really, only a isre is quite sufficient.

About the 3, it's like the point 2.

2.

- They look equally 'clean' to me. In fact, if anything the identifier method is cleaner with multi-word/complex operands because it is much simpler to see what is being done.
Consider this:
if ($regex(moo oink moo, /o(?=[aeiou])/gi)) { ... }
if (moo oink moo isre /o(?=[aeiou])/gi) { ... }
I don't know about you but I find it very easy to see what the $regex() method is doing whereas the isre operator gets lost in the jumble. In many ways I'd prefer to the isin/iswm operators to be identifiers.

3.
The trouble with having custom operators is that it would probably make parsing if conditions slow/difficult.
For example:
if (moo isprime isin moo) { ... }
Now mIRC has to parse that text and check for the existence of an operator with the name of each word. It's not the same as identifiers or commands because they have syntactic elements that indicate what they are (appearing at the start of a line, prefixed with $ sign). If mIRC only comes up with one match then great, use that operator, but what happens if more than one matching operator appears in the text? Which does mIRC use? Even if you wrote your script with all this stuff in mind and made sure it worked, there's always the possiblity of someone using another script alongside it which 'infects' yours by adding operators that clash with text in your comparisons.

Without quoted strings it's very problematic to have custom operators and, as I pointed out in 2. above, we're probably better off without them anyway.

well, i still prefer operators; and if khaled to consider my suggestion (i think there are 0.1% of possibility ), probably the mirc will get an $wildmatch too, so don't worry about this

about the point 3, you are right

Hmm, another idea about regexes. i would like use regex definitions in menu prefixes. anything like using


instead of


the $ that marks that the match is regex can be -r or anything else

Usually people don't have a multitude of windows open that would demand a need for using a regular expression in a menu definition, for example, how often would you require checking if a particular window's name begins with 3 numbers followed by 6 letters? But if you have a genuine need for it, until it's supported, you could of course just run $menu through an $iif in a menu * event

Huuuuuuuum.. really, i can do this without the regex switch.

i am coding an addon that every time i run create a new window and connect a mud (like a telnet client, but can connect in various servers), and i use regex to match it because is far more simple get the number of the window with regsub. like this:



so $clio_window(1) = @MUD (1) and $clio_win-1($clio_window(1)) = 1

and i would like to do anything like

and etc