Forums Developers Multiple Spaces

We're still forgetting yes we can have the consecutive spaces returned, but aliases still delimite just like the events do. All passing would have to be redone to accomidate the consecutive spaces. If you pass
(_ = space)
/myalias this_is_a______demo

You still get $4 as demo in the alias. But then again, you could also have the "$rawtext" in the aliase.
(I would prefer a $R1 $R2, etc variable tho. >:D)

Well that's whay I was thinking of - the entire language having null token support rather than just an exception for the on TEXT event.

I mean what is so wrong with using chr160? Its a good replacement, and would keep compatability.I do say that events like on text, on actions, etc should support multiple spaces, but then after that its up to you to keep the consecutive spaces in tact whether it be by means of $replace, or otherwise when passing to a alias or variable.

It will NOT keep compatibility. Char 160 is NOT a space. It is a non-standard extension to the ASCII table. Many fonts use it, yes, but not all. It is NOT standard.

well i tried several fonts and it alway echos this, for example

//echo -a a $+ $str($chr(160),10) $+ a
returns
a a

You tried several _windows_ fonts. Other OSes might not be the same. And remember, IRC != mIRC. People are using other OSes.

well as far as i know mirc is only compatable for windows, and this is a mirc forum :tongue: ,well if its not a mirc forum then i think the name should be changed from (mIRC Message Board)

I agree with codemastr - I think it is pointless sending characters to the room that programmes on other operating systems cannot understand. I have used $chr(160) for internal functions such as spacing information in dialogue listboxes as the TAB just puts an ugly square in place rather than shifting the text along a bit. Mind you I'd love to TAB, I just can't be bothered asking if anyone knows a way to do it.

[]1,1space[]4,1There's 5 spaces >:D

as i said this is a mirc message board, so why should i even consider other os's when mirc is only compatible for windows :tongue: ?

Because there are chat programs for other operating system, making any text sent over IRC subject to any circumstance. Why not make it universal >:D

speak english when speaking to illiterate people

[offtopic]
Just wanted everyone to know that 1K posts has been reached on this forum
[/offtopic]

But a $rawtext identifier or null token support would be the best solution IMO

What he means is that when you send a unique character to the chatroom only mIRC users will be able to see it. Users of other programmes will not. We all know mIRC dominates by far over anything else and all else added together but that is not to say that mIRC should 'go it alone'. There has to be some sort of conformity or at least discussion with the authors of other programmes and indeed IRCd's when wanting to commit to a feature or function that would otherwise stand alone.

ok

ty watchdog.. couldn't have explained it better myself (or else i would have)

The issue has been resolved in mIRC 6.1. The message sent for just about any event is $mid($rawmsg,$calc($pos($rawmsg,$+($chr(32),:),1) +2)). Using single identifiers (including $replace() and $+()) can be done without loss of multiple spaces. The /set command doesn't lose them ether. So you can /set a %variable to something containing the original line of text with its spacing preserved. Of course, you can't /echo it because /echo loses the spaces. What you CAN do is use /loadbuf -e on a file containing only the name of the %variable you want to echo. It's a complicated process, but in the end it lets you echo things without losing the spaces and without putting in hard spaces.

i have found another way to do it without using /loadbuf (which wont wrap the same way as /echo -iN, ect.)



it basically sets a variable for the message, then /bwrites the variable to a file. write would probably also work. also, the $eval(%rm,0) should write the text '%rm' to the file, but instead it writes it's contents. if i try to /bwrite $rawmsg or just the variable, the spacing is lost.

after it is written, the file is read into memory and /breplace is used to replace all spaces with $chr(160). in turn, $chr(160) is turned into ^b^b$chr(32)^b^b (to preserve the spacing without using different characters in place of a space) and tokenized so that $1- will contain the original text but with extra spacing included.

the only downside is that any $chr(160)'s in the original text would be converted to a space, but since $chr(160) is commonly used as a replacement for $chr(32), i am willing to accept this.

The only differences in behavior between /loadbuf and /echo that I've noticed are that /loadbuf automatically scrolls to the bottom of the window, and that it doesn't keep track of your place properly, which indeed may be annoying enough to make your method worthwhile. /loadbuf wraps the same way, to my knowledge, if you use the -pi2 switches. Also, I see no reason why you cannot use $replace($right($rawmsg,$+(-,$pos($rawmsg,:,2))),$chr(32),$+(,$chr(32),)), and thus avoid reading/writing a file, and losing $chr(160).

But for me, I can accept no loss of information.

that also works. i knew i shouldnt post the first solution i found ;/