This unfortunately can't be done unless mIRC creates a new quoted string construct. The idea of space tokenization is deeply rooted all the way down to the parser.. spaces are what mIRC uses to delimit commands and their respective arguments. $1- could never hold multiple spaces because it's tokenized by spaces to represent each word (or arguments, depending on context). Again, it's a deeply rooted principle of the language. $1- could only preserve spaces if something like the literal "hello world" (quotes included) counted as one token. Although that would be my suggestion, (I doubt it would break that many scripts), it's unlikely to be implemented.
No Argv, you are mistaken. $1- most certainly can contain sequential spaces. $1- simply means that it points to the first delimited parameter and everything following it to end of line. Nothing after the first parameter has been parsed yet. So sequential white space characters remain as is.Or at least they should. ViRC does this properly.
I can not believe mIRC still suffers from this. I mean it does cause problems. For example, working with a file that has a space in the first or last character of the filename will always generate an error when a script tries to access it. I'm talking about a file w/ a name like " stuff.txt". That first space will *always* result an in error. Also it's just rather pathetic. Maybe not so much ten years ago. But now yes, pathetic.
I don't care if it breaks scripts to get this fixed. That's never stopped Khaled from making changes before that broke things. And this needs to be fixed.
I think since quotes really serve litle purpose other than to specify parameters that include spaces, it should just leave everything within quotes as is. This is the best solution.
