Forums Feature Suggestions event matchtext &

on *:text:.&:#: echo -a matched $matchkey

Doesn't work when I test with ".test" for example (without the quotes obviously), whilst there's no reason for it not to.

For those who don't, know, & matches a "word", therefore .& should match a dot followed directly by a word, in my test case, . followed by the word "test".

Putting .* as matchtext is not the same, since * matches any string, whereas I'd like it to match only one word, like ".test"

I could imagine that since & matches "word" you are supposed to use it in the matchtext delimited by spaces, but I don't agree with that.

Obviously, I'm aware of "work-arounds" like using regex matchtext or parsing within the event body, but that's not important, imo & should match a word (a string that doesn't contain spaces aka a sequence of non-space characters) even when you have characters touching it in the matchtext part.

Matches just fine for me.

Ack I don't know why it didn't work yesterday, It seems to work now, however:

Try this matchtext .&. which doesn't match .test.

Neither does &. on test.

Edit scrap my initial reply. I can see a few cases where this could be useful -- I agree, the behaviour of '&' could be improved for those cases, although mIRC would have to actively differentiate between the '&' being followed by a space, or by any other character, in order to maintain its efficiency (as it currently uses no backtracking).

Maybe another character could be substituted in place of & . Maybe the + character would work.

on *:TEXT:.+ & *:*:{
;RE /^(\.[^ ]+) ([^ ]+) (.*)$/
echo -a Command is $1 (\.[^ ]+)
echo -a Nick is $2 ([^ ]+)
echo -a Reason if $3- (.*)
}

-genius_at_work

That's not necessary, as the added functionality that FiberOPtics suggests would not break backward compatibility. The '&' already works instead of the '+' In your example, anyway.

By the way, only by mere accident did I discover why for me the .& matchtext didn't work, it's most likely because I had a space appended to my text string when testing this with my clone. I ran into this today when testing something else with & in it. Anyway, as mentioned &'s behaviour can still be improved to work in more cases.