Forums Feature Suggestions Preserve blank space in editbox

$chr(160) *is not* a space. You can't do /echo -a $replace(<string>,$chr(160),$chr(32)).

--

I didn't.

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.

Not sure about the name $sp(), but I love the concept and think it would work well!

I recall that did screw up some unicode characters on the same line. Is that still the case?

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.

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.



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.

Doesn't tokenize do exactly what you want?

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.

You people do know that /returnex is the only command that preserves spaces...

Really it just doesn't matter anymore...

Trying /help /returnex didn't bring up anything in the help file, thus I have to wonder where you're getting this command from?

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.

You do know that the Feature Suggestions forum is the only forum that allows us to post feature suggestions...

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



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



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



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?

on INPUT happens after ENTER is pressed. That means that there is nothing in the editbox anymore. It is now in $1-.