Don't tell me it isn't a bug.
It's not a bug. There, I told you.
mIRC uses space as a delimiter for commands, so multiple spaces will always be ignored when evaluating a line of code unless you pass it to mIRC indirectly. It's not that mIRC can't "display" spaces from a variable, it's that mIRC will parse the spaces from the variable and then handle them the way it handles all spaces parsed in a line of code. Those spaces actually *are* passed through the scripting pipeline, but only up to the point where your echo command is evaluated, at which point they are destroyed just like Collective described.
Example:
- The line
/echo -a %myvar would turn into "/echo -a MY
<space><space> VALUE" after variable interpolation.
- Once executed and tokenized, the arguments would be passed into the "echo" command with $1 = "-a", $2 = "MY", $3 = "VALUE".. meaning $1- = "-a MY VALUE". This is why your spaces seem to disappear, because after interpolation they are no longer "data", they are delimiters in mIRC's syntax.
- This goes for all /commands where tokenization happens for $chr(32). Note that this is why you can preserve spaces (better) using $identifiers, because the tokenize character there is $chr(44).
- This is why
$len($str($chr(32),5)) == 5, because it doesn't pass through any /commands which use space tokenization. This proves that mIRC does not destroy your spaces, but uses them as token delimiters in the parsing stage. This proves that this is an inherent syntax rule and cannot be a bug.
Dislike this functionality all you want, but at least have the maturity (and intelligence) to understand that this is a basis of mIRC's syntax and parser and an inherent part of the language, good, bad, or neither.
