I can't find a place in F1 help where it gives an overview of how /commands work differently from $identifiers. For those who are used to other languages, they're surprised how some things are impossible without complex manipulation.
For example, users come to the help channel for help with scripts, and are surprised that there's no way to send a channel message containing 2 spaces following a period in a sentence without workarounds involving either using binary variables and the /parseline command, or by writing it to disk and using /play.
So it would help if F1 had something that described how to use a generic command, without the need to have identical descriptions at several. Such as mentioning the fact that all /commands strip the extra spaces from their command string, with a very few exceptions like /returnex
(*1) A possible work-around for specific /command cases would be like a -switch that overrides the behavior of pruning spaces from the string, in which case it would be up to the user to make sure that they conform to commands which otherwise assume the spaces are being stripped.
For example, there are some things like /copy /write /remove /rename /mkdir that exist as commands, but there's nothing like $write() that would preserve spaces in the string being written. While they can use /bwrite to write the consecutive spaces, it would be hard to use the /bset command directly, without writing a string containing a substitute for the double space and then use /breplace to change them to double spaces.
However the stripping of allegedly-extra spaces also means that you can't delete a filename containing doublespaces unless you use $shortfn(filename), but as I understand it, the existence of short filename equivalents isn't guaranteed to exist, since it can be disabled as part of the OS.
Also, using $shortfn doesn't always help, because it would also change filenames that don't have spaces, such as corrupting the /copy if you used it as the destination name LONGFI~1.TXT instead of Long Filename.txt
While it probably won't work for the DCC SEND/GET protocol to have the filename actually sent having doublespaces, there's currently not a way to rename a file to rename it without the extra spaces in order to send it as the similar filename.
Well I take that back, there is an obtuse workaround that can create a filename with doublespaces, but it would be a complicated sequence involving copying the file from its $shortfn to a temp filename that's long enough, adding the file to a zip, and then editing the zip in a way that you can change the filename to contain double spaces. Then, you'd need to unzip to the same directory, using the 'o' switch which has the potential of overwriting other files if you didn't make sure the zip doesnt also contain other files too, because the 'o' switch needs to be used both for overwriting a filename, as well as extracting to a directory name that already exists.
A more generic solution for enabling commands to see consecutive spaces would be if there's a -switch or \CommandPrefix that changes the behavior so that %var or &binvar gets expanded to their literal contents without the spaces being stripped. The prefix-method would be better because the switch-method wouldn't have 1 specific switch that could be used across 100% of commands. This would be 1 solution that would enable a lot of commands like /echo /msg /copy /write to use the extra spaces who formerly were not able to. It would eliminate a lot of interest in either having /returnex style of commands to repeat the same behavior except for also preserving spaces, or to have identifiers like $echo(string,switch) to do the same thing with the extra spaces.
(*2) Would be helpful to either have a summary which documents how switches are handled, or in some cases create another switch which eliminates the ambiguity.
https://forums.mirc.com/ubbthreads.php/topics/265400/re-msg-on-dashed-nicks#Post265400For example it could also mention how the parameter beginning with the hyphen is assumed to be switches, and that it ignores any switch that's not currently defined, and that you can use the lone - in some cases to get the needed behavior.
Examples which potentially deserve a new switch:
(*2A) When someone has a script which detects someone using a 'bad word' and puts them in their /ignore list, which won't always work:
<OFF> message containing bad word
<$me> you are now in my ignore list!
/ignore $nick
* Ignore is off
While the script can be fixed by changing to "ignore - $nick", it would be more straightforward if /ignore could be presented as having the -a (add) switch that's the default behavior when not using ON|OFF.
(*2B) From normal usage of clipboard, there's no documented syntax to replace the existing contents of the clipboard with an arbitrary string, it's just the default when not using any switches. While they could use "/clipboard - %variable", it would be nicer if it were documented with something like a -o (overwrite) switch that's the default behavior of replacing the existing contents. An example where this causes unintended results if the scriptor doesn't know they don't know about using the lone hyphen as a switch parm:
//clipboard password | clipboard $remove($read(test.txt,nt,1),$,%,|) | msg $chan $cb
works fine as long as the file was not created like:
/write -c test.txt -abc test
in which case, result: passwordtest
(*2C) For the /help info attached to normal usage of filename-related /commands, or in a preliminary summary, there could be some mention of the fact that /copy needs doublequotes around filenames containing spaces, or when the source filename begins with a hyphen. And that $shortfn() needs to be used for filenames containing doublespaces, and that a /copy /write don't offer a way to create a filename containing doublespaces.
