Forums Feature Suggestions Preserve blank space in editbox

It would be nice if the blank spaces were preserved in the editbox string $1-.

i.e.

(types in editbox)
A word spaces and more words.

As everyone knows when you send this to channel the multiple blank spaces are replaced by one blank space.

Until (and if) Khaled implements this, there is a 3rd party DLL called Spaces.dll

This unfortunately can't be done unless mIRC creates a new quoted string construct. The idea of space tokenization is deeply rooted all the way down to the parser.. spaces are what mIRC uses to delimit commands and their respective arguments. $1- could never hold multiple spaces because it's tokenized by spaces to represent each word (or arguments, depending on context). Again, it's a deeply rooted principle of the language. $1- could only preserve spaces if something like the literal "hello world" (quotes included) counted as one token. Although that would be my suggestion, (I doubt it would break that many scripts), it's unlikely to be implemented.

You can always use $editbox($active) to get the non-space-modified data in the editbox if that's all you're looking for (since identifiers tokenize by commas, not spaces), but you could never use it in any commands, so it wouldn't help much.

Yeah that makes sense. Thanks

If its so hard to do, then why can it be done with a dll so easily? I don't mean to doubt anyone, I'm asking more out of curiosity. It seems to me that if it can be done using a dll, it shouldn't be incredibly hard to add into mirc's coding.

Spaces are preserved, to some extent.



They're just not preserved when parsing arguments, for obvious reasons... if they were preserved, then $n (where n is some positive number) could very well be $null before the end of the list:


Preserving spaces in a aesthetically pleasing manner, for mIRC isn't difficult.

As I mentioned, when you pass values to identifiers they're tokenized by commas, not spaces. In that case, spaces are not yet messed with. spaces.dll takes data via identifiers so spaces aren't touched and then bypasses tokenization when sending this data to commands. mIRC would need a similar construct to denote that spaces need to be ignored during tokenization for a part of or all of a command. I suggested quotes, but it could be done with some builtin identifier syntax like $sp(a <space> <space> ... b) so as to not change the grammar, theoretically anyway.

Consistency? Usefulness? Rather than suggesting some silly idea of a function "$sp()", which "skips tokenization" (and thus forces you to do the tokenization in your function call), why not ask for the $identifier functionality of most of the builtins to be exposed? $sp() wouldn't be all that useful- just an aesthetics thing... If you're concerned about aesthetics, there's a few thousand other reasons not to use mIRC.

var %tablename = cosmic greeting
var %itemname = hello, world!
var %space = $str($chr(32),128)
noop $hadd(%tablename,%itemname,hello %space space!)
noop $echo(%itemname $+ ; $hget(%tablename,%itemname))

You're the one who seems concerned about aesthetics, since I never brought it up. The idea of a quote construct exists in every language, $sp would be the equivalent; it has nothing to do with aesthetics. For example, Tcl has a similar grammar to mIRC when it comes to function arguments in that spaces delimit arguments. To preserve spaces, Tcl has a "string" construct using quotes. I'm not sure if you bothered to read what I wrote originally (apparently you haven't), but since quotes can already be used by scripts, there is a backwards compatibility issue at hand. The solution that avoids backward compatibility issues would be to use an identifier instead of "" syntax. Again, it's not about aesthetics, it's about selectively preserving spaces at tokenization. It would not "force" you to tokenize yourself, since the whole point is to *avoid* tokenizing. Example: for /mycommand a $sp(b c) d, the resulting $1- would be: $1=a, $2=b c, $3=d

I'm not sure what your example was trying to prove, but I don't see the relevance. $echo does not exist, and a construct like $sp would still be necessary for /commands of which there are thousands. If your idea is to abolish /commands, that's definitely not going to happen.

I think he mean that /command could be called as identifier like when creating an alias and check $isid for exemple.
I do like this idea, but considering $tips and /tips, it would break scripts since /tips couldn't be called as $tips because it already exists for another purpose

likewise with /timer and $timer

Yeah, there are of course many others cases, it was an exemple

Even without $tips, $timer, etc... the ability to call a /command via $identifier format was disabled a while back because of security issues, if I recall. A faulty $eval would allow a user to easily do something like $quit() or even worse, $run(). There are other ways to mess with scripts with faulty evals, but this was too easy to exploit. I'm not sure that would change back regardless of the compatibility issue with identifier name collisions.

In any case this solution isn't possible and $sp() might be not a silly idea.

argv0, I don't recall any time when that was possible. scid would be a better example. $& is an almost insignificant part of the lexer that could be extended in this case.

Since we're working with a GUI app here, it would be nice to be able to align content correctly, but we can't... we can at least make smart suggestions that take a step forward. I won't go into my rant about using spaces for presentation's sake, but it's also silly because of the name. It's silly because the intended behaviour of such a function is to free up functionality, but it's still likely to have the same constraint that exists in many areas of MSL.

I suggest a better name would be $format, and it needs extension to provide flexible functionality. Here's a few ideas: default colour, prefix/suffix trimming and trim character, prefix/suffix appending and append character, then the request at hand, space preservation.

No Argv, you are mistaken. $1- most certainly can contain sequential spaces. $1- simply means that it points to the first delimited parameter and everything following it to end of line. Nothing after the first parameter has been parsed yet. So sequential white space characters remain as is.Or at least they should. ViRC does this properly.

I can not believe mIRC still suffers from this. I mean it does cause problems. For example, working with a file that has a space in the first or last character of the filename will always generate an error when a script tries to access it. I'm talking about a file w/ a name like " stuff.txt". That first space will *always* result an in error. Also it's just rather pathetic. Maybe not so much ten years ago. But now yes, pathetic.

I don't care if it breaks scripts to get this fixed. That's never stopped Khaled from making changes before that broke things. And this needs to be fixed.

I think since quotes really serve litle purpose other than to specify parameters that include spaces, it should just leave everything within quotes as is. This is the best solution.

MeStinkBAD: I'm not sure how I'm mistaken. When $1- is tokenized by spaces, as I mentioned, the individual words will never contain spaces. A new construct would need to be added to prevent this. "Nothing after the first parameter has been parsed yet" is not true at all. Tokenization occurs fully on the input.. and even if it was true, that would not change how spaces are handled.



It's actually stopped him from implementing plenty of things. In fact of the hundreds if not thousands of feature additions, only a handful have contained changes that would require existing scripts to be modified. Khaled has been very good about maintaining compatibility and making sure that scripts written in previous versions will continue to function with little or no change in the future.

The problem with a change like this is it would cause enormous amounts of breakage if it was implemented with a *new* syntax, hence the $sp identifier suggestion.

I don't know what world you live on Argv... but please think thru things before you going yapping on about stuff you make up as you go along.

You state:


Let me clarify what you are saying. You mean that the identifier is processed before the command, and that the command strips out multiple spaces. This is the same w/ $1-.

Also, what the hell is up w/ your $sp idea? It's an IDENTIFIER! When used w/ any command it suddenly becomes useless. Hmmm... really didn't think it thru did you...

Look Khaled has dug himself into a hole so deep now that he really can't get out. You honestly think if a Unicode version is ever released (which is a big if) that it won't drop it's current script language (which is not grammatically consistent in the least). I've been working w/ mIRC for like 13 or 14 years now. It's clear that a lot of bad decisions we're made early on. I recall when Khaled pissed off every other IRC client developer w/ his wacko color protocol. It didn't matter that an existing one worked just fine, until he released his and just made things hell for the developers. He always said he would revise it but did he? Nope...

Well that is some rant...

Can we stay on topic please.

The matter is resolved for me.

Ive always used $chr(160) for spaces in text design.


This works for me.