OK
The first confusement I found was discovering what arguments are send to subroutines
when they're called back.
Actually, all the signals in signals.txt were fairly self-explanatory, for instance:
"print text stripped", WINDOW_REC, SERVER_REC, char *channel, int level, char *text
That's easy to understand; I'd use a
my ($window, $server, $channel, $level, $text) = @_;
at the beginning. Signals are quite easy to understand.
However, I looked through perl.txt and signals.txt but didn't find any mention of what
happens
when a function is called back from a
Irssi::command_bind("command", "cmd_handler");
After experimentation I found the arguments were more or less $data, $server, $channel
Unless it's in there and I missed it, you might want to make a mention of that.
Also, I was wondering... it might be informative if you throw a copy of the
IRC-related RFC documents
in there so new Irssi script-writers can craft together server commands easily with a
reference right there
and ready for them.
Another nitpick with perl.txt is the definition for
Server::ctcp_send_reply(data)
Send CTCP reply. This will be "CTCP flood protected" so if there's too
many CTCP requests in buffer, this reply might not get sent.
What exactly should "data" contain?
--
Spirilis
GnuPG Public Key available from certserver.pgp.com
Key ID 92E1516E
GPG Fingerprint: BA2A E8C0 D4BA 604A 997D F809 D609 C9AC 92E1 516E
