It's great but it's very strange how $* works. I really would like to see $* works as the other identifier, without odd things or at least have an explanation about why he works like that.
$* was added before the scripting language supported while and goto loops, to allow scripts to iterate a command over a set of values. $* is purposefully no longer documented. Instead of $* you should use while or goto loops.
Hum, just because $* doesn't works like other $ident, you can't use it without space around it, have to use /scon -r to be evaluted.I know that it's not a bug, i just would like can use it whitout scon -r and space, like the other.
In short, the `~$* text that $* evaluates to, acts as a marker to allow for search-and-replace of this marker (with $1, $2, etc) after the evaluation of the line is fully complete. What the marker looks like is not important, as long as it can't reasonably be the result of the evaluation of anything other than $*. `~$* is "weird" enough to fulfill that requirement.
And here's a confirmation of this, along with two other (mostly unimportant) observations: //tokenize 32 a b c | var %a = `~$* | echo -a $* :: %a :: `~$*THIS_WILL_BE_GONE :: NOT_REPLACED:`~$*
On a related note, the following doesn't work as expected: //tokenize 32 a b c | echo -a $* $upper(d e) (gives "`~$* D E") This happens when there's a literal space in an identifier parameter.
Even though this topic is dealing with editbox, I gather this is related to why I was seeing only the 1st nick instead of all 3 highlighted nicks when I add line to nicklist menu:
.Op +o ( $$1 $2 $3 ): mode # +ooo $$1 $2 $3
and when I changed to:
.Op +o ( $* ): mode # +ooo $$1 $2 $3
I was seeing the `~$* in the menu label, regardless whether 1 or 3 nicks are highlighted.