/RAW PRIVMSG nick :bla_bla__bla___bla____bla_____bla
(replace _ with blank space character)
doesn't produce the intended result..
instead, it produces:
<nick> bla bla bla bla bla bla
(same goes with the /msg command)

just please don't try to pursuade me that I'm wrong istead of mIRC.

mIRC commands have never supported multiple consecutive spaces, does it really suprise you that /raw is any different?

This has been reported many times in the past. You can use sat's spaces DLL to work around it (instead of using a bunch of yucky $chr(160)s).

Regards,

That DLL is a very nice DLL, unfortunatly, if you wanted to process the string with an identifier before echoing it to the window or sending it to a server, you cannot.

I think khaled should make mIRC allow consecutive spaces in strings, as this would simplify things greater than any DLL could.

Yes you can, $identifiers such as $replace,$remove,$regex,$len do support consecutive spaces, since the parameters are separated by commas. Ofcourse,
/echo -s $replace(<aaaaa>,a,$chr(32))
will just display < > because the /echo command collapses the spaces of the result of $replace.
//echo -s $len($replace(<aaaaa>,a,$chr(32))) will correctly display 7, but you cannot use /var or /set to assign it to a %variable, any /command will have spaces collapsed before it executes...


This is nearly impossible to do from the current code I think, This would most likely require a complete rewrite of the scripting engine and also the language semantics. I doubt Khaled feels like working 3 years on a complete new scripting language that does support multiple spaces and retains the great features of the current.

To show you just some problems:
if ( hi * iswm $1) echo -a $2-3
Is the space before hi and after the * part of the search string or not? What if there were 2 spaces between the * and iswm? What if $& was used to continue on the next line, that would give 6 extra spaces in an alias definition inside a loop. Does $1 (the first word) include spaces? If 2 consecutive spaces after hi, is $2 empty then? or is $2 2 spaces and the next word?

You're wrong.

Use the search feature and look up multiple spaces.

There are lamers everywhere


anyway, thanx Mentality, I've read so many times about that double space problem, but, is it so hard to change the mIRC code a little bit, so the string identifiers should be enclosed in quotation marks (") and the quot.marks sholud be used with the escape character like \" or so..?

I mean mIRC is really a great client, but this is SO big flaw, not to mention the file systems problems with the file names which have double spaces in its names..

I think that can be solved by using the quotations.. but then again, I'm not sure how many work does it require..

Greets and thanx for your replies.

yes not being able to do two spaces is so so so bad, the sky is falling the sky is falling.

If you should be concerned about anything its the anoying fact that you can only do $chr(0) using binary values. oh no the sky is falling the sjky is falling agin!

As has been stated, it's more trouble than it is worth. Rename your files if you have issues. There's no need for a file with multiple spaces, anyhow.

If that was true, the Windows, Linux, BSD programmers etc. wouldn't bother making an effort to make those OS-es support long file names (including the multiple spaces)

I am familiar with workarounds for this bug, but I just wanted to say that it could (maybe) be solved with those quotation marks and escape chars..

I didn't say it couldn't be done. It just isn't worth the headache of all previous scripts that use strings being broken after adding that.

Adding escape characters is one thing... they won't break many other scripts. It's entirely different to add quotes, which will break almost all scripts with strings. And, as mentioned, it would mess up the command line entry that uses the exact same command formats as in the script.

Much better to use known workarounds or remove multiple spaces in filenames. There really isn't a good reason to use multiple spaces in filenames.

Maybe a better solution, instead of breaking every known script by introducing such requirements, is to improve the variable handing to allow multiple spaces in a variable only.

There is a -n switch to global variables to indicate that value is to be treated as plain text. Perhaps a -q switch could be used to indicate that value is going to be surrounded by quotes, and therefor preserve the value 'as is' without loosing multiple spaces etc.

There are of corse a few things that come to mind, such as when the -q switch is used mirc would have to treat the line in a non-greedy fasion. That is continue to the last quote charactor in the line rather than stopping at the first (to allow quotes/comma/etc within the variable itself).

Just a thought, if possible would allow you to set such a variable then use that preserved variable in scripting and output. It's not the most efficient solution of corse, but something of this sort would be better than using quotes all over the scripting language and breaking everything currently availible.

Double consecutive spaces already are preserved in variables themselves - it's the parsing/tokenizing of the commandline where things go wrong. This is the case for /set as well as any other command (although /set behaves slightly differently at this point) so changing only /set would not solve anything.

As far as I can see it (and I have looked into it a bit, hence the DLL mentioned earlier), the only two things we really need are:
1) a way to allow commands to be parsed without losing the spaces. See my suggestion here, which is simple to implement and easy to use.
2) a version of $1- as set by mIRC in events and callbacks such as "on INPUT" and $findfile's 'command' parameter, that also leaves all double consecutive spaces in. In fact, I doubt that changing the standard behaviour of $1- this way will affect any existing scripts at all - I can elaborate on this but I don't think I should do that in this thread.

This would allow scripters to get rid of all problems with double consecutive spaces; in cases ranging from simple /msg commands, to theme engines, to MP3 players (double spaces in filenames), etc.

Oh and while I'm at it: adding support for true quoted strings (as also mentioned in another thread) would be such a fundamental change to mIRC's script parser, that I can safely say that it just isn't going to happen. Ever. And IMO, that's only a good thing.

Are you sure double spaces are preserved in variables? I looked into it before my previous post and it certainly did not seem the case to me.


Opened ini in notepad, line reads "n186=%zztestvar 1 2 3 5 6"

This is the case either in command line or within a script, therefor i must assume that the set alias strips the double spaces when settings the variable, hence my suggestion that it be able to behave differently and infact preserve the text 'as it'

Edit: i read the post you linked to, your command prefix suggestion is basically the same as i was suggesting above. It is indeed a better solution than just the use of a variable for preserving the text as is, but it is infact the same basic concept as i was getting at with using a switch.

since that is a command with a command line, and he said multiple spaces are lost in command lines thats where its loosing spaces, not that they cant be stored in a var.

//set -s %zztestvar $replace(1....2.......3........5..6,.,$chr(32))

-s just so u see it stored em with spaces.

Ah, after getting some caffeine and rereading your post I see what you're getting at. Yeah, it's basically the same concept, using some kind of 'marker' to tell commands not to strip spaces.