When abusing $chr(160), the following little script gets the deal done already. I didn't know about $regml(1), so this thread bumped me in the right direction, all right
on &$^*:text:/(.*)/:#:{
echo -bfi2lmqt $chan $+(<, $left($remove($nick($chan, $nick).pnick, $nick), 1) , $nick, >) $replace($+($chr(32), $regml(1)), $+($chr(32), $chr(32)), $+($chr(32), $chr(160)))
haltdef
}Basically, what the script does is, whenever you receive a line of text, my script picks it up, does some things to it like color the text between "" characters, color and underline links, etc... It also combines messages from other users that were split over multiple lines back into a single line. For that, since only the end user will see it, I think I'm going to stick to $chr(160) until I hear someone having problems with that.
It does more or less the same things for messages by the current user sent to other users. Displaying it for the current user of course can use $chr(160) again. As for displaying text to others, I'm not sure, yet. If the /play command requires the clipboard or creating/deleting a file every time you enter a message, then I'm not going that way. Perhaps I'll just allow the end user to choose between using $chr(160), using double bold tags or letting leading/multiple spaces disappear.
As for my bot(s), I'll have to look into spaces.dll, I guess. I'm currently using $chr(160) to properly align ascii characters, and I've been doing so for a while. I never heard anyone having problems with the alignment so far, but it might be wise to keep my options open.
Keeping leading and multiple spaces is not really a requirement. It's just that I've already been using this script for a while, and am just improving it over time. So far it just ignores leading/adjacent spaces, but if there is an easy way to keep them intact, I'd be happy to.
EDIT: Changed the code slightly to keep a leading space intact.
