Actually, what I described was not enough.
For the token string lists I use, it should be token-specific.
For example, one list (a queue) has a format:
; $1 = id $2 = status $3 = network $4 = irc command $5 = mirc switches or <none> $6 = irc parameter or <none> $7 = irc command flag(s) or <none> $8 = system
; $9 = system related data $10 = passthrough system or <none> $11 = passthrough system related data or <none> $12 = priority 00 (first) - 99 (last) $13 = $ctime
..using 215 as token separator.
Now, suppose it sends a /silence +*!*@* to server, server may reply with the named raw SILENCE, in that event, I use condition if (!$SC_IRCQueue_Check(SRV,SILENCE,$1,<none>)).
Alias SC_IRCQueue_Check puts 'SILENCE' and the value of $1 on the correct positions, resulting in a matchtext token-string of 13 tokens (the total amount tokens in a line of the @window), of which some are * (any string on that token position) and 3 literal (network, SILENCE and content of $1, being the silence mask).
This means I need to be able to specify which token positions should be treated as literal and which should handle wildcard symbols as wildcards.
This all could be done in a line per line loop, where every line is tokenized, and some tokens are compared with == and some with iswm (or maybe == *). The problem though is, it becomes alot slower than /filter since alot more is done through the script engine instead of machine-closer executable language.
Your regex using alias is a black box to me since I dont know regex.
So first question is, can that alias be written so that it accepts a per-token flag wildcard symbols to be taken literal or not?
And second question is of course native support by /filter for this. I think /filter is the most powerful of all mIRC commands, it already has alot switches, so the correct parsing of them may already be a demanding task.
It already knows tokens, the -t <position> <ascii token separator> provides sorting.
A quick not so thought-through proposal could be similar to /window -t[N,...,N], for example /filter -T2,3,7 32 would treat the tokens on positions 2,3 and 7 as literal, using a space (32) as token separator (uppercase T to distinguish from the existing -t).
Of course, this is all quite some work, and my proposal could be too personal to take it into account. My situation is a big script, so every bit performance gain gives extra 'room' to provide more without mIRC hanging too often in the trees.
Though, mr. Author of mIRC reacted on a performance issue I had with /filter so this could already have eliminated the step to open the code editor with focus on the /filter code.
