I would like to suggest isquery and isdcc to be added to the list of operators available for if statements.

For some this may or may not be a "great" idea, considering we do have methods in which to find out if a window is a query window or DCC window, however, we have ischan (channels can be looked up by not using ischan) so why not these.

Putting it simply, all they need to do is return if it is an query or DCC window we are currently in, just like ischan (and yes, $query($nick) etc would do the same trick, as would the equivalent dcc identifier).


So, can we please have an isquery and isdcc operator for if/while statements?

Im not against this and yes, there are ways to do it now (if ($window($active) == query) etc) Add it in, couldnt really hurt anything

This is not a comment on your suggestion, I just wasn't sure if you know about $window().type. landonsandor mentioned this (I think) although he forgot the .type property. $window(<windowname>).type returns the type of window (channel, query, chat etc).

Yes, I know about that, but thats only usefull if you want to detect what type of window/s you have open.


$query($nick) will tell you if you have a private message open with $nick (or anyother parm you provide), and the same is said of $chat.



All isquery and isdcc should return is yes or no if a query exists (or dcc)

eg:

if ($me isquery) {
asdasdasd
}

You may have already explored this option, but couldn't you make an alias?

if ($isquery($me)) command
else command

alias isquery {
if ($query($1)) return $true
return $false
}

that's pointless..

if ($isquery($me)) command
else command

Two more letters than actually just doing so..

EDIT: For future refernece, making an if is not needed.

alias isquery {
return $query($1)
}

yup, I sure did forget about that ;-) Thanks for the fill-in

The problem with this alias is that it won't always work.


For instance, I've made a custom /say alias, and it will not work whatsoever.

Like I've said, all it has to do is return true or false if a query or dcc exists, and I'm in it (which is pretty obvious, because its a tad hard for you not to be in a query).

It doesn't return active window, just a simple t/f.

I completely fail to see your point. Since you compared isdcc and isquery with ischan, I assume you'd want it to work the same way. ischan is useful when you want to tell whether the first argument of the condition is a channel window or not. Similarly, if (<something> isquery) would be useful when you want to check whether <something> is an open query window or not. How is that different from if ($window(<something>).type) or if ($query(<something>)) ? All three conditions (your proposed isquery and the already existing $window().type and $query()) give TRUE if <something> is an open query window, otherwise they all give FALSE.

The only possible advantage of isquery is that it's a few characters shorter than $window().type. Still, it's exactly the same number of characters as $query().

if blah isquery -> 15 chars
if $query(blah) -> 15 chars
if $window(blah).type == query -> 30 chars

The answer to the question "then why do we have ischan" could be that ischan was implemented in v4.5 and $chan() in v4.7, so ischan was initially the only way to determine whether <something> is a channel.

Isn't (something ischan) faster than ($chan(something))? If so, I guess it would have a very little difference, anyway.

Yes, I would expect it to be a little bit faster (an operator is generally faster than an extra identifier), but I didn't consider this difference to be of any significance.

Ok.

isquery is just another method of determining window type.

It works in a similar manner as to ischan (excepting that ischan returns if #chan is a channel you are on).

isquery would work in a similar manner, excepting to be a quicker method to return $window(something).type


I am currently using $query(blah) instead of $window(blah).type

However, it shouldn't exactly matter if you use $query(blah) or blah is query.

And as has been mentioned, the isquery/isdcc should be slightly faster.

Anyway, these are just suggestions.