Forums Feature Suggestions Event $text identifier to complement $1-

Dear Khaled,

I would like to request the identifier $text that complements the token parameter $1-, but is not tokenized, and is not lost when using the /tokenize command. This identifier would be available to all On Events where $1- is currently populated.

• Reasons:
  
  $1- returns $null when a user sends a message or notice that consists entirely of spaces.
  
  $len($1-) == 5 when a user sends the message "<100 spaces>HELLO<100 spaces>".
  
  $rawmsg can no longer be reasonably parsed by script authors owing to new server/client CAP support for message tags, which grossly augments the expected server protocol output. The script author would have to be privy to all the possible $rawmsg augmentations in order to handle them and 'find' the user string ($text).
  
  $1- cannot be reworked with /tokenize without first storing the original value to variable. While all other identifiers such as $nick $address $target $event $chan etc all enjoy immunity to this.
  
  $1- does not automatically propagate to aliases called from events, unlike all other event identifiers as listed above. Eg, $nick is available to any custom alias or identifier that is called within an Event. $text would be, too.

There is a work-around solution. I do not enjoy having to employ this solution in every script event I write.
This only works for event types with a match-text parameter.

FWIW I think this is a strong argument. One could argue about whether those message tags were a good idea in the first place, but now that mIRC does support them, parsing $rawmsg has definitely become a whole lot more complicated..

Thanks, Sat!

As far as msgtags being 'grossly augments' to the IRC protocol, as the RFC defines them:
If included, they will *always* be a single space-delimited token
If included, they will *always* start with @
If included, they will *always* be at the start of a server-sent message

Also note that IRCv3 msgtags aren't directly tied to CAP. At any point that a client encounter's a server message fitting the above, regardless of CAP modules enabled, the first token is to be assumed as msgtags. Because of this, its simply a matter of checking if ^@\S*\x20 matches and then removing it to get the semblance of pre-msgtags server message:



---

With that said, I do agree that $text would be a beneficial inclusion; the biggest reason being non-loss data after tokenization.

Bump. Pleeease!

Let EVENTS produce $text identifier, similar to the $1- portion of $rawmsg. Inherited by called aliases the same way $nick and $address and $target is. Not stripped of contiguous spaces. Not lost with /tokenize.