Forums Feature Suggestions Please add NOOP command, or "quiet" .XYZZY

Edited: Skip this post and see Online's below.

Khaled, please add a NOOP command.
Presently people have to var %nul = or .!echo -q in order to achieve the same results. I wouldn't mind using .XYZZY except that it doesn't "quiet" as it 'should'.

For those who don't know, NOOP stands for No Operation, and is a common command in many text programs and internet protocols... mostly used for debugging purposes, or anywhere a command is needed but no action is necessary.

The circumstances where NOOP would be useful are anywhere identifiers such as $findfile $finddir $regex or $regsub are used and the results are of no importance, but would cause an "Unknown Command" error if used on their own.

- Raccoon
(Comments of var %nul = or .!echo -q already exist & are just as good, would be redundant as I already know this. I could even /alias NOOP return but I don't wanna. Let Khaled decide if NOOP should be added or not.)

I would like to see .$identifier()

Shorter, cleaner and makes sense (since dot already silences commands).

SWEET!

Do you mean at the start of the line? If so then you might aswell just ask for $identifiers to be allowed at the start of the line, no . necessary anyway if there's nowhere for the value to be sent to. If you mean anywhere in a line then you're still left with the same problem since you'd have to use another command on the identifier, and then the command would presumably have an 'insufficient parameters' error if for example you did /echo .$identifer seeing as there's no text to be output.

In scripts they already are allowed at the start of a line...

Good point. This is what I get for making posts at 3am. Why am I even online?

'Cause your a nerd :P

You do have a point, unless I misunderstood Online's suggestion. Currently, $identifiers are allowed to start a line in a script, but their return value will be used as a command. So, fex, ".$regex(blah,/blah/)" would actually result in mirc executing the /1 command, prefixed with the silencing dot. Changing mirc to not try to execute the return value would be inconsistent with the way it works in general. For example, having a variable as a command works fine (and I currently use it in a few cases), I would expect an identifier to work the same way.

Regarding the original suggestion, /haltdef is another alternative, if there is no halt-able event involved. I'm fine with /!.echo -q but I don't mind having a command that's 5 chars shorter (that's the only benefit I see with /noop; speed shouldn't be an issue since !.echo -q is already very fast).

Yeah I realised that when I woke up this morning. I'm too easily coerced when I'm tired.

imho the . shouldn't even really be necessary. I mean other languages have no requirement that functions MUST store their value somewhere. Why can't mIRC be smart enough that if you just do

$regex(......)
to discard the value?

The only thing I've ever seen where the value is actually used "as a command" i.e. you want to execute the return value is by backdoors, things like a ctcp event that executes $1-. I can't think of any time I've seen a legitimate use of it, and if you really wanted to still execute you could do something like // $+ $1- which would tell mIRC you do want the return value to be executed.

Think of .$identifier as if it was $null($identifier).

A (working) script like this,
according to the suggestion could be changed to,
...not a great implementation, but wouldn't hurt if added. Also, it doesn't conflict with the way mirc works, ie. $identifier in a new line would still be treated as a command as long as it isn't prefixed by a dot.

Actually that most likely wouldn't work.

.$regsub(1st round) .$regsub(2nd round)

mIRC doesn't let you put two expressions on the same line unless you use a |.

Why not?  ".$identifier" would work anywhere in the script, exactly as "$null($identifier)" does, and we can have more than one of them in one line, like this,

$null($input(hello)) $null($input(world))

(this line actually does nothing besides bringing up the input boxes)

Yes, but imho at least, when you use the . prefix you are now treating it as a command, not as an identifier.

The . is meant to make the following $identifier return nothing in advance. I apologize my first post wasn't clear.

Actually, your post was perfectly clear... and it should be obvious that only the first $identifier needs to be proceeded with a '.' while any subsequent identifiers may be freely added to the line as you would with any command.

.$regsub() $regsub() $regsub() $regsub()

- Raccoon

But you're then creating inconsistencies for the use of . all for the sake of not having to type !.echo -q.

Explain, what use of . is that you speak of.

From the help file:
If you want to force a command to perform quietly ie. without printing out any information, then you can prefix it with a "." fullstop.

The theme here is "quiet". Yes, it's a different type of quiet... with /commands it only quiets display output... but with $identifiers it will quiet "inputs" from being sent to mIRC and the server.

I can't imagine anyone becoming honestly confused with this use of the prefix. It shouldn't be any more confusing then commands that being with ! to prevent it being processed as an alias, and identifiers that use ! to delay evaluation.

- Raccoon

Technical aspect of the . prefix for $identifiers.

Recognizing that it may be possible for an $identifier to evaluate to a string which the user may wish mIRC to process as a command... the way that the identifier evaluates is important.

Assumed: $1 == "command"

.$1 ::= quietly dumps "command" into the abyss.
. $+ $1 ::= evaluates to ".command" and executes it, quietly.

.$ [ $+ [ 1 ] ] ::= quietly dumps "command" into the abyss.
. [ $+ [ $1 ] ] ::= evaluates to ".command" and executes it, quietly.

The key here is that the . must be included with the $identifier at the time it is evaluated. If the $identifier is evaluated, and a . happens to get prepended to the result... it should be handled as a normal . prefixed command.

- Raccoon

A prefix is actually a good idea, so from this aspect I rather like your suggestion. However, currently, the ".$ident" expression makes mirc execute the command /.<value-of-ident>. The dot works as usual (silencer) here. So, instead of changing the parser like this, I think it would be simpler and cleaner if another character was used. Now that I think of it, why not the "!" ?