Your alias does the job that you wanted it to do, but it has nothing to do with the problem I've showed, which is: there is something wrong with $chan and $snicks.
You must mean with the problem you
introduced. $chan and $snicks are out of scope if you don't call them from within a channel (with or without selected nicks). Presumably, $chan and $snicks do not get filled with data until an event happens in that channel, such as on INPUT (which internally also watches for <tab>, thus allowing you to tab-complete $snicks while in the editbox for that channel) or a popup event. on JOIN will not populate $snicks either.
You can't access them directly from an ON DIALOG event
No surprise here, as on DIALOG does not take place within a channel. $chan and $snicks are out of scope.
and you can't reproduce anything like them in this situation in a clean(IMO*) way.
This is incorrect. I can reproduce anything about that behaviour that I choose to include. Your statement here is your opinion, nothing more. I have no problems scripting this sort of activity. I would even venture to guess that there are others who have this same curious lack of a problem with this.
But the very problem is why you can't access them. After all, you can access $active. $chan is not really needed, using the same $active.
Exactly the truth. There is no $chan in any dialog. There is always $active and and there is also $dialog().active, two different identifiers.
$snicks sometimes is.. and you can't reproduce it.. you can't use it properly even with a timer - I'll explain this later.
Your code doesn't reproduce anything like these identifiers. It's not able to refresh that data, that's all. Then it doesn't do what's wanted.
No, you may not reuse $snicks if the event that checks it did not originate in that channel. If an alias is being used to check for its presence, then it must be triggered from within the channel with the selected nicks. /window -a will make another (channel) window active, but it will not refill $snicks in the new channel. This is true, even if you call an alias from a timer because $snicks is still out of scope.
No, you may not call $snicks at all if you do not do so from inside the channel itself. $snicks takes no ($chan) parameter like $snick() does. I can perhaps see your point about adding $snicks($chan) to return the $snicks from $chan. However, again we're back to identifiers not being filled with data simply because you /window -a to them.
You should understand that, first of all, what I really want isn't a scripted solution, since I can handle that - I am interested, though, in any clean way to script it, and that's why I asked for it and modified yours anyway.
I assumed you could read script; that is why the majority of my second post was just code. I tried to anticipate what you wanted by including the timer to "follow" the channel you had selected. Obviously, I guessed your intentions incorrectly. For this, I do apologize.
My goal was to show you a common way in which you can rebuild your own $my_snicks for whatever channel was active, refreshable whenever you choose. It can, indeed be done...very easily.
alias -l my_snicks return $didtok(Frog,2,44)
Edit: qwerty has just pointed out to me that $snick(#channel) returns the comma-delimited list.
