mIRC Homepage
Posted By: DJ_Sol Preserve blank space in editbox - 25/09/09 02:03 AM
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.
Posted By: RusselB Re: Preserve blank space in editbox - 25/09/09 04:58 AM
Until (and if) Khaled implements this, there is a 3rd party DLL called Spaces.dll
Posted By: argv0 Re: Preserve blank space in editbox - 25/09/09 05:15 AM
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.
Posted By: DJ_Sol Re: Preserve blank space in editbox - 25/09/09 09:13 AM
Yeah that makes sense. Thanks
Posted By: Thrull Re: Preserve blank space in editbox - 29/09/09 06:39 AM
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.
Posted By: s00p Re: Preserve blank space in editbox - 29/09/09 09:17 AM
Spaces are preserved, to some extent.

Code:
var %x = $len($str($chr(32),128))
echo -a length of % $+ x: $len(%x)


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:
Code:
alias one {
  var %x = $len($str($chr(32),128))
  echo -a length of % $+ x within one: $len(%x)
  two %x
}

alias two {
  echo -a length of % $+ x within two: $len($1-)
}


Preserving spaces in a aesthetically pleasing manner, for mIRC isn't difficult.
Code:
; input: x (number of spaces, integer form)
; output: expected output of $str($chr(32),x)
alias spaces {
  return $replace($str($chr(32),$1),$chr(32),$+($chr(32),$chr(2),$chr(2)))
}
Posted By: DJ_Sol Re: Preserve blank space in editbox - 29/09/09 05:57 PM
Quote:
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).
Posted By: argv0 Re: Preserve blank space in editbox - 29/09/09 07:13 PM
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.
Posted By: s00p Re: Preserve blank space in editbox - 03/10/09 12:34 AM
Quote:
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.


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))
Posted By: argv0 Re: Preserve blank space in editbox - 03/10/09 01:18 AM
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.
Posted By: Wims Re: Preserve blank space in editbox - 03/10/09 01:39 AM
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
Posted By: RusselB Re: Preserve blank space in editbox - 03/10/09 05:21 AM
likewise with /timer and $timer
Posted By: Wims Re: Preserve blank space in editbox - 03/10/09 05:31 AM
Yeah, there are of course many others cases, it was an exemple
Posted By: argv0 Re: Preserve blank space in editbox - 03/10/09 06:32 AM
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.
Posted By: Wims Re: Preserve blank space in editbox - 03/10/09 03:36 PM
In any case this solution isn't possible and $sp() might be not a silly idea.
Posted By: s00p Re: Preserve blank space in editbox - 04/10/09 05:18 AM
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.
Posted By: MeStinkBAD Re: Preserve blank space in editbox - 09/10/09 03:33 PM
Originally Posted By: argv0
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.


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.
Posted By: argv0 Re: Preserve blank space in editbox - 09/10/09 05:44 PM
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.

Originally Posted By: MeStinkBAD
That's never stopped Khaled from making changes before that broke things.


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.
Posted By: MeStinkBAD Re: Preserve blank space in editbox - 14/10/09 06:09 PM
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:
Quote:
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.


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...
Posted By: DJ_Sol Re: Preserve blank space in editbox - 14/10/09 07:36 PM
Can we stay on topic please.

The matter is resolved for me.

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

Code:
Editbox: test     test

/echo -a $replace($editbox($active),$chr(32),$chr(160))

This works for me.
Posted By: MeStinkBAD Re: Preserve blank space in editbox - 14/10/09 11:18 PM
$chr(160) *is not* a space. You can't do /echo -a $replace(<string>,$chr(160),$chr(32)).

--
Posted By: DJ_Sol Re: Preserve blank space in editbox - 14/10/09 11:30 PM
I didn't.
Posted By: argv0 Re: Preserve blank space in editbox - 14/10/09 11:35 PM
Originally Posted By: MeStinkBAD
Also, what the hell is up w/ your $sp idea? It's an IDENTIFIER!


Please read: I said construct, not identifier. There's a significant difference between an identifier and a change to mIRC's grammar. The use of identifier-like syntax would just be for backwards compatibility. Again, I don't expect you read that part.
Posted By: hixxy Re: Preserve blank space in editbox - 17/10/09 06:28 PM
Originally Posted By: argv0
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.


Not sure about the name $sp(), but I love the concept and think it would work well!
Posted By: Knoeki Re: Preserve blank space in editbox - 19/08/10 01:17 PM
Originally Posted By: DJ_Sol
Can we stay on topic please.

The matter is resolved for me.

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

Code:
Editbox: test     test

/echo -a $replace($editbox($active),$chr(32),$chr(160))

This works for me.


I recall that did screw up some unicode characters on the same line. Is that still the case?
Posted By: argv0 Re: Preserve blank space in editbox - 19/08/10 04:47 PM
Now that mIRC is fully unicode this is no longer a problem ($chr(160) *is* the unicode codepoint for NON BREAKING SPACE)

In fact, $chr(160) can finally be recommended as a viable solution since it will work across all fonts. In 6.35 and prior versions, $chr(160) was not guaranteed to be an empty space for many fonts, and should not have been used (although lots of scripters misused it). Now that mIRC is using the Unicode codepoint for a non breaking space, this character is the same glyph universally.

Of course, this gets you "spacing", but is a) not compatible with non-Unicode clients and b) does not handle tokenization, ie. it is not a true space, as mentioned above. If you use this character to space text you would confuse scripts that tokenize by spaces. Perhaps $gettok should be able to take a list of token delimiters rather than a single one. Until tokenization routines can handle this, it's still not a great alternative to true multiple space support via a construct or something.
Posted By: hixxy Re: Preserve blank space in editbox - 19/08/10 04:58 PM
If possible, although this might be incredibly hard to implement at this stage, I would like to see something that can specify how arguments should be tokenized.

Code:
//tokenpass 46 myalias hello world.goodbye world.1.2.3


This would pass these arguments to /myalias:

$1 = hello world
$2 = goodbye world
$3 = 1
$4 = 2
$5 = 3

And of course spaces would be preserved.
Posted By: Darwin_Koala Re: Preserve blank space in editbox - 19/08/10 10:53 PM
Doesn't tokenize do exactly what you want?

Code:
 tokenize 46 hello world.goodbye world.1.2.3
myalias $1-  
Posted By: Wims Re: Preserve blank space in editbox - 19/08/10 10:59 PM
Quote:
And of course spaces would be preserved.
Posted By: hixxy Re: Preserve blank space in editbox - 20/08/10 07:10 AM
That's not the same at all.

With that, /myalias would receive these tokens:

$1 = hello
$2 = world
$3 = goodbye
$4 = world
$5 = 1
$6 = 2
$7 = 3

The command I am suggesting would tell /myalias which delimiter to use to separate tokens, and it would preserve spaces.
Posted By: MeStinkBAD Re: Preserve blank space in editbox - 22/08/10 08:24 PM
You people do know that /returnex is the only command that preserves spaces...

Really it just doesn't matter anymore...
Posted By: RusselB Re: Preserve blank space in editbox - 22/08/10 09:50 PM
Trying /help /returnex didn't bring up anything in the help file, thus I have to wonder where you're getting this command from?
Posted By: starbucks_mafia Re: Preserve blank space in editbox - 22/08/10 10:08 PM
It's an undocumented variant of /return that preserves spaces.

Just what that has to do with the topic at hand or why it "just doesn't matter anymore" is anyone's guess.
Posted By: hixxy Re: Preserve blank space in editbox - 23/08/10 12:28 PM
You do know that the Feature Suggestions forum is the only forum that allows us to post feature suggestions...
Posted By: Thels Re: Preserve blank space in editbox - 29/08/10 09:57 AM
Originally Posted By: DJ_Sol
Can we stay on topic please.

The matter is resolved for me.

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

Code:
Editbox: test     test

/echo -a $replace($editbox($active),$chr(32),$chr(160))

This works for me.


Does this still work somehow? When I use the following two line of codes:

Code:
alias f6 echo -a Editbox: $replace($editbox($active), $chr(32), $chr(160))

on *:input:*: echo -a Editbox: $replace($editbox($active), $chr(32), $chr(160))


And enter "test test" in the editbox, upon pressing F6, I get:

Code:
Editbox: test  test


As intended. However, when I press enter, it simply states:

Code:
Editbox:


Which seems to indicate that the editbox is cleared before on input triggers. "on ^*:input:" also doesn't work.

Is there any way to read the editbox value when on input triggers, or keep track of all changes to the editbox without requiring a specific hotkey for that?
Posted By: Riamus2 Re: Preserve blank space in editbox - 29/08/10 02:48 PM
on INPUT happens after ENTER is pressed. That means that there is nothing in the editbox anymore. It is now in $1-.
© mIRC Discussion Forums