$parms depends entirely on the tokenization of parameters across multiple routines/features in multiple contexts.
isn't $parms completely tied to $1-?
/tokenize is setting $1-; is $parms not being set by /tokenize because it's a command and therefore, $1- and $parms cannot be different after a /tokenize command (a fine argument to me, but I'm assuming that $parms should be set whenever $1- is set)? If not I'd like to hear from you about why /tokenize isn't setting $parms.
It seems to be that way since $parms is filled for custom command call, but not for custom $identifier call, and the only reason for this I can think of is the same as above: inside an identifier $parms and $1- would be equal since identifier indeed preserves spaces.
That being said, I'm pretty curious as how the $iif part is intended.
I'm still assuming that $parms is tied to $1- here, so if $iif sets $parms to $null (way of talking), I'd think that $iif call dealing with $1- in the condition could also see $1- being $null? However this has never been reported as far as I know.
alias testparms echo -a $parms - $iif($parms,yes $parms, no $parms) - $parms | if ($parms) echo -a yes $parms | else echo -a no $parms
type /testparms, the result is not making any sense, $iif is calling mIRC's /if function so if /if does not 'break' what is so different about $iif?
