I'll make my problem simple to khaled,
go to any window, type
/echo -a b<space><space><space><space>c

result "b c"

I've had a hell of a time with this for the
longest time, the scripting environment
is always chopping out the spaces, and
it messes up my string parsing.

I noticed that you can type
"a<space><space><space><space>b"
in a text window, and it does fine, If khaled
would fix this, I think alot of scripters
would be very happy.

even this forum parses excessive
spaces, let me make it clear to everyone
space parsers are bad!

P.S (bring back the help icon)

it's very probably your web browser that removes the extra spaces. They tend to do that (I think it's actually some soft of standard).

This has been discussed several times before. There are some ways around the limitation, most of which are not pretty. There have also been suggestions to use things like binary variables (allow echoing of binary variables and pass binary variables to scripts).

I suggest you look around for other threads on the subject.

next time you ask a question it would be nice if you did a search on the subject, or read up on the details of the feature. If you aren't already aware, spaces are something mIRC has been "chopping" out ever since the birth of the language. mIRC tokenizes all information it receives (when it receives it in script). Therefore when you say $1-, you're saying "The tokenized version of my text", which is inherently space stripped, just by the fact that it was tokenized. There is no way around this- its the method that the language parses information. This explains why you can have multiple spaces in an unscripted IRC environment (IE. talking in a chatroom) but lose that ability once you put in an ON INPUT event that does the command /say $1-

madewokherd: Its not a browser limitation, the html standard eliminates 'white space'. For this reason, it makes it possible to indent such tags at <tables>, <tr>, <td>, etc. without getting the uneccisery spaces. e.g.



As for mirc, if you want to align tect, you may find my snipplet someone valuable, as it bypasses it (for if you are attempting to make a table, or soemthing). Otherwise, bear with it.

By the way argv, I did search the forums for "spaces" and I found no links suggesting it. perhaps I didn't look hard enough, but I did look :P

Also, you said mIRC obviously sorts by tokens, and thats great and all, but an extra identifier could be given at the handling of the event/alias that is the "REAL" string, without the tokens being parsed, basically we are being limited
only to the usage of tokens to deal with our parameters.
think about it.

I don't find that to be a limitation at all, since you always have binary variables to do your dirty work with spaces. and just like was mentioned, you can use aliases to fake spacing.

you're missing the point, the point is, this is a suggestion to khaled, something that he can fix. I don't see why you should defend something that could be better?

yes there are work arounds like replacing spaces, and using binary, but the fact remains it is clumsy. Even WITH binary variables, I still encounter the same problems, you got to come out of binary some time, and when you do.. it gets tokenized.

I know its easier for me to ask him to fix it, but from what I understand, all he has to do is make an edit to the way it handles parameters and set an identifier that gives the exact result, (no token parsing).

You make that comment like it's once simple addition. From my standpoint its not.

Not only would it be a failry decent modification to the parsing agent, but also a severe hit to scripts. A lot of scripts have loops dependant on "until token is null" i.e. the last word; causing these scripts to break.

As far as for a 'clumsy' method, it's laster all these years thus far. It can't be too bad. And when you say that it gets tokenized when removed from a binary format, thats not true. Maybe with your method of parsing, but its completly possible to do it otherwise.

er, I don't really understand what you meant by this modifcation breaking other scripts, it would be an addition, not altering the functionality of scripts, but by adding a new identifier instead to give the real text. (making it optional to use)

you're probably right about the binary part, i'll figure that out later, but you shouldn't have to rely on binary.

everyone used windows 95 for years and some still do, are you saying its not clumsy just because people has made do with it? that answer should be obvious. I don't understand why you people want to stick up for this problem, if I didn't know any better, you act like you wrote the code yourself, like I said, stop sticking up for other methods and maybe something will be done preferably sooner into the future :P

you say fix as if its broken- its not broken- its merely a part of the language- deal with it.

use something like this

alias spaced return $replace($1-,~,$chr(160))

/echo -a b   c
/echo -a $spaced(b~~~c)

result
b c
b   c


or if your just writting echos etc, use $chr(160) to begin with, oddly if u want to use alt-160 u actualy have to use alt-255, dont ask me why.

if your working with pre existing strings with spaces, then use
%whatever = $replace(%whatever,$chr(32),$chr(160))

hey dave, thanks for the work around, i would do it that way, but what i'm writing requires the real spaces. I'll just have to do it the binary way. by the way, if you wanted to do chr 160 with alt (with the actual #), type alt + 0160

you know what argv, I say what I mean, so don't confuse yourself. I was offering a suggestion for a future mIRC, thats how i'm dealing with it, and I think its a little backwards of you telling me to deal with it, obviously I will have to deal with it regardless of what you say.

You can echo the real spaces using /loadbuf -e (evaluation). Put the spaced string in a %variable. Put the name of the %variable on its own in the file (this way, you can reuse the file and don't have to write to the disk every time). Then use /loadbuf with the evaluation switch to echo it.

I know, this doesn't solve the problem of getting the spaces in an on input event.

NrWarren -
the point is, this has been requested and whined about so many times in the past, you think Khaled would have done something about it by now. The reason he hasn't is most likely that it's a pretty tough problem to solve given the constraints of the parser. I imagine lines are tokenized even before they get to the script parser, which would mean that he would have to rework the parser to handle script code (parse an identifier such as $fullline or something) before it handles script code (note the redundancy?) - Redoing the parser is not worth his time and effort, and certainly isn't that important just so users can echo "REAL" spaces.

I actually replied in a different thread on how to catch spaces in a on input
https://forums.mirc.com/showthreaded.php?Cat=&Board=scriptsandpopups&Number=67894

I find that timers + $editbox tend to cause problems sometimes here by not triggering between typing and pressing enter. Also, what if you, um, paste something? That solution, even for a workaround, is just not good enough for me.

That timer goes off 40 times a second, its faster than the keyboard repeat rate, as for pasting, well thats up to what you code the timer event to do, it should take every event as a new line of text. The Only time i have seen it beaten is when i was loading text into the editbox using /editbox -n

Well it's still unusable for many, because it's simply not using spaces at the end. $chr(160) isn't a space in many fonts, one can't assume this. Granted it's only taking account of echoed text in your example, not what's sent, but you simply can't send text with multiple spaces.. and this is needed more than just echoing text like it should be sent and still sending it all messed up.

yes, it does get all messed up... if you use the edit box in a custom window, the spaces are killed in your on *:input:... event.

Hi i
ve heard various ppl bitch and moan that it would be hard to modify the parser to allow for spaces to be left in output etc.

argv0
The reason he hasn't is most likely that it's a pretty tough problem to solve given the constraints of the parser.

now i also hear u can use binvar's as a get around. now why not have khaled add in something simple where a new identifier to be used in place of $1- ..but as a binvar alternative. so what is passed on is also passed on as a binvar to the next level. or even to output on screen. or even for those who are avbout ot bitch that having everything being passed on ass binvar aswell as the normal way would impact on speed. well there's always adding somethign to the start of the start of a command. such as .msg would make its execution silent to the user. why not have a different letter used as to tell the parser to pass spaces on ad shown in the following line. i dont see how this could be all too hard. so Khaled. lettuce know if its possible. and maybe just fix this whitespace nighmare ....