Forums Bug Reports Bugs already reported but not fixed

1) When you trying to stick some text with $N like $1's, if text contain number, mirc cut the text :



2) There is another strange thing :



This will echo "te" but i think it should return $mid(text,1,2)Ga since the $mid shouln't be evaluate and here :

the $mid isn't evaluate.

I think the second thing you've shown should give an error.

Why ? this can be reproduced with any $identifier that use bracket ().


Where is the error ?

It's returning "te" as mIRC evaluates the $mid* thingie (you're using "//" in your echo command). If you want it to return "$mid(text,1,2)Ga", use /echo, not //echo.

But I think this should return an error, too:
Everything appending a text token identifier (don't know how to call this, like the example "$1's") is appended, but not everything appending the return of an alias/command, like $mid().
"$me's" never worked: how shall mIRC now whether to call "$me" and append "'s", or call a custom alias named "$me's"
The return of a nonexistent alias is $null, and //echo -a $null returns an error: * /echo: insufficient parameters

I'm not sure but i think you misundestood what i trying to show, i don't want to return anything, there is just a problem, if 1$mid(text,1,2) return 1$mid(text,1,2), so $mid(text,1,2)1 should return $mid(text,1,2)1.


I agree but it's not the case here, $mid()Ga can't be a name of an alias (custom or not) because there is bracket.
If mirc parsed it as an alias, i'll should have in echo :

Ok - now I get your point, thanks for clarification.

Regarding the error message: I have "identifier warning" disabled.

This might be regarded as a bug, but also I can imagine it's acting this way by design.
For me it is some "syntax gray area" - and I'm not dropping my own "should return $null/error" rating for the issue...yet

I agree but if it was a normal behavior (like $1's) the text after the $identifier should be returned too.

I'd imagine the reason that it doesn't give an error when you append text to the end of an identifier is because of props. If a prop is invalid, the identifier will still return the value as if there wasn't a prop.

//echo -a $chan(#channelname).topic2

That will return the channel name rather than an error. If the prop isn't valid, it's removed. Of course, you could make it throw and error if there's no "." there. I'm just showing why it probably doesn't give an error.

Good point, I don't think about that before, but $mid doesn't support .props (it's the same for other identifiers like $asc, $chr etc...), so if the text isn't a props (event invalid), mirc should return the text as a "plain text" :

I disagree about it displaying plain text. It should give an error message, not display the code. Yes, if you put text before the identifier, it will display as plain text, but that's because there's no way to know if it's supposed to be an identifier if there isn't a $ as the first character.

Hum i don't care in fact, but which error mirc can be returns ?

* $ident() invalid format ?

Whatever Khaled feels like using would be fine, I'm sure.

The first bug concerning the behavior of $N'text with text that contain number is still present is 6.31

None of these are bugs, they're a reality of the mIRC parser.. that's why they were never "fixed". You really shouldn't be nitpicking about silly things like how mIRC reacts with code that violates the language syntax since the expected result is *UNDEFINED*. The invalid identifier warning you get is a convenience, not a requirement or guarantee. If you do something mIRC can't understand, that's your bug, not mIRC's.

As far as $1XYZ goes, that's a specific *feature* of the language, the same way the parser allows "//echo -a $mircdirSUBDIRECTORY" without using $+ for convenience. Not a bug.