Forums Feature Suggestions The multiple spaces fix!

Ok, there are like... a billion posts about "why can't mIRC display multiple spaces" etc. This attempts to solve that problem by using binary variables. Basically, think of /braw as a binary variable version of /raw. Now the difference between /braw and a regular mIRC command is that /braw evaluates binary variables, meaning:
/braw PRIVMSG #chan : $+ &thedata

mIRC would evaluate &thedata to whatever is in that variable. Now, since we're interacting with the IRC server, this binary command can't function like regular binary commands. What I mean by this is, &thedata should only be evaluated up to the first $cr $lf or $null, thats just because of the way IRC works. The purpose of this isn't to be able to send binary data to the IRC server, it is to be able to send multiple spaces.

Now thats only part 1 of the fix. Part 2 involves something a bit different. For ALL aliases, events, identifiers, etc mIRC not only creates things like $1 $2, ... it creates &params. &params contains the parameters EXACTLY as they were passed.

And lastly another alias, /bdo. /bdo is a version of the mIRC parser that supports binary variables. For example:
/bdo echo -a &thedata
That would work just like calling /echo except &thedata is evaluated to its contents, again this should probably work like /braw with the evaluation. So how does this work exactly?

alias msg {
bdo msg &params
}

That for example would make /msg allow multiple spaces.

The idea isn't exactly the cleanest, maybe others have some suggestions on how to make it cleaner, but it has the potential to work.

I agree with /braw, or as I suggested /raw with a -b flag to treat &binvars specially.

This should be very possible. I wouldn't use the word 'evaluate' but rather 'print' the data contained in the &binvar at the point which &binvar appears in the string. This would require some secondary evaluation layer the same that $* exploits with `~$*

I also support the idea that all events and aliases should have &rawmsg and either &1 &2 &3 etc, or simply &params. I believe &1 &2 &3 may be unnecessary considering these would be space-delimited like their $1 $2 $3 counterparts... which means stripping any padded spaces. &1- or &params should be the only necessary binary sibling, for ease and sanity sake.

/bdo on the other hand, may be a tad too difficult for Khaled to impliment globally that supports all commands. Every command uses its parameters differently, /bdo could only really be useful for server-output commands (which /braw will already handle), or file-output commands (/bwrite), or screen-output commands... which should be /becho.

And yes, all of these uses only data up to the first NULL character should be printed... and in most cases, only up to the first CR or LF. Any following data is ignored.

Unfortunately, whenever I suggest any of these in the past... people still fixate on mIRC's current inability to handle &binvars... so I would like to re-iterate that these suggestions are FOR mIRC's expanded handling of &binvars.

- Raccoon

One other thing I just thought of. This is because of $rawmsg. That identifier (which I and I assume others thought would help with the multiple space stuff) is 100% useless. Why? You can't do _anything_ with it really. As soon as you do any processing on it, all the spaces disappear. Meaning, I tried $gettok($rawmsg,4-,32) to get just the text. Well that removes all the extra spaces. The feature is utterly useless. So what I'm suggesting here is an expansion to /bset, one that would allow it to receive multiple spaces. Like I could /bset -mt &rawmsg 1 $rawmsg and that would preserve all the spaces in $rawmsg and you can now do whatever manipulation you need to do using the binvar.

- Not strictly true. Using $regsub you can assign the full text to a variable and then process that variable with any built-in identifiers (again within $regsub mostly). eg.

You're right, although you must admit, that's not exactly the cleanest code in the world. But also, I didn't test, but wouldn't assigning to %moo cut off any trailing spaces? Like for exampe (I'm using _ because the forum doesn't let you use multiple spaces): "this is a test ____________" Wouldn't all those trailing spaces get cut off simply because of the way variables work?

Just tested and it doesn't appear to. I think the trimming effect you usually get with variables is just down to mIRC trimming spaces from the end of lines when a variable is being assigned. Luckily $regsub isn't limited by that.

It might not be the easiest code in the world to make or work with, but at least it's possible now. It's a hell of a lot better than the previous best method (reading /debug output).

To be honest, I was too tired to read every line in here, but if you just wanna have spaces in your massage or your file...

I use this:

alias spaces {
var %space = 
var %i = $1
while (%i > 0) {
var %space = %space 
dec %i
}
return %fun_space
}

 are two times underline

with this alias:

/msg $nick Hello $+ $spaces(6) $+ there

will have 6 spaces.

As I said, maybe I misunderstood you all, but if not this maybe helped ^_^,
CySlider

But then, how would one use that binary variable to actually display text properly? /echo won't do it, then it still seems useless to me.
The only method that comes to mind is something like "bwrite file 0 -1 &text | loadbuf $active file", such a bad workaround IMO.. along with a loop. I didn't test anything, but I guess that would be slow when used a lot in any related event (ON TEXT etc.)
Am I missing something, though?

Nope, you didn't miss a beat.

There is absolutely no way to display a series of *real* spaces without inserting control characters or hard spaces, short of using /loadbuf /filter or /play... which all require writing to the harddrive. I don't know, but I rather not half the life of my harddrive just to display spaces.

We need an /echo that natively supports &binvars.

- Raccoon

Yes, when a scripter is writing a message to be displayed he can use an alias like that to get around the space issue. But when receiving text from another user that hack is useless, currently the way I described is the only way to retrieve the fully spaced text.

The variable couldn't be displayed directly with /echo, however you could pad consecutive spaces with control codes using $regex() to get the same visual effect. This could potentially cause processing speed issues for mIRC if you have a large buffer where many users are typing multiple spaces or someone floods with multi-space messages. All I was really demonstrating before was that $rawmsg is useful and can be used to retrieve, process, and/or manipulate incoming text containing consecutive spaces. I think displaying the text is entirely possible using a loadbuf hack, especially with mIRC 6.1's new file handling functions. You could probably do something along the lines of:
check if text contains consecutive spaces using $regex - if it doesnt just /echo and /return
check if file is already open with $fopen() - if not open it with /fopen
write binary variable to file with /fwrite
loadbuf text from file
That way you wouldn't be constantly opening and closing the file (a slow process). I only just came up with this and I haven't even used any of the new /f* functions, so it's possible that there's a flaw in that idea. I know it's not ideal, a /echo &binvar would be nice, but at least it is possible now to do this.