Cinch provides three kinds of events:
-
Events mapping directly to IRC commands
For example
:topic
, which will be triggered when someone changes the topic, or:kick
, when someone gets kicked. -
Events mapping directly to IRC numeric codes
For example
:"401"
forERR_NOSUCHNICK
, which is triggered when trying to operate on an unknown nickname, or:"318"
forRPL_ENDOFWHOIS
, which is triggered after whois information have been received. -
Events mapping to more abstract ideas
For example
:leaving
whenever a user parts, quits or gets kicked/killed or:message
, which is actually a synonym for:privmsg
, the underlying IRC command.
Events of the first two kinds
All events of the first two kinds behave exactly the same: When they get triggered, the handler will be passed a single object, a reference to the Message object.
Example:
on :topic do |m|
# m is the message object
end
We will not further describe all possible events of the first two categories.
Events of the third kind
Events of the third kind can each have different signatures, as they
get passed objects directly relating to their kind, for example the
leaving user in case of :leaving
. This document will describe all
events of that kind, their signature and example usage.
Note: Because all handlers receive a Message object as the first argument, we will only mention and describe additional arguments.
:action
The :action
event is triggered when a user sends a CTCP ACTION to a
channel or the bot. CTCP ACTION is commonly refered to simply as
“actions” or “/me’s”, because that is the command used in most IRC
clients.
Example:
on :action, "kicks the bot" do |m|
m.reply "Ouch! Stop kicking me :(", true
end
:away
The :away
event is triggered when a user goes away. This feature
only works on networks implementing the “away-notify” extension.
Example:
on :away do |m|
debug("User %s just went away: %s" % [m.user, m.])
end
See also the :unaway
event.
:ban
The :ban
event is triggered when a user gets banned in a channel.
One additional argument, a Ban object, gets passed to the handler.
Example:
on :ban do |m, ban|
debug("%s just banned %s" % [ban.by, ban.mask])
end
See also the :unban
event.
:catchall
:catchall
is a special event that gets triggered for every incoming
IRC message/command, no matter what the type is.
:channel
The :channel
event is triggered for channel messages (the usual
form of communication on IRC).
See also the :private
event.
:connect
The :connect
event is triggered after the bot successfully
connected to the IRC server.
One common use case for this event is setting up variables, synchronising information etc.
:ctcp
The :ctcp
event is triggered when receiving CTCP-related messages,
for example the VERSION request.
:dcc_send
:dcc_send
gets triggered when a user tries to send a file to the
bot, using the DCC SEND protocol.
One additional argument, a DCC::Send object, gets passed to the handler.
For example usage and a general explanation of DCC in Cinch check Cinch::DCC::Incoming::Send.
:dehalfop
, :deop
, :deowner
, :devoice
These events get triggered for the respective channel operations of taking halfop, op, owner and voice from a user.
One additional argument, the user whose rights are being modifed, gets passed to the handler.
:error
:error
gets triggered for all numeric replies that signify errors
(ERR_*
).
:halfop
This event gets triggered when a user in a channel gets half-opped.
One additional argument, the user being half-opped, gets passed to the handler.
:leaving
:leaving
is an event that is triggered whenever any of the following
are triggered as well: :part
, :quit
, :kick
, :kill
.
The event can thus be used for noticing when a user leaves a channel or the network, no matter the reason.
One additional argument, the leaving user, gets passed to the handler.
Be careful not to confuse the additional argument with Cinch::Message#user. For example in the case of a kick, Cinch::Message#user will describe the user kicking someone, not the one who is being kicked.
Example:
on :leaving do |m, user|
if m.channel?
debug("%s just left %s." % [user, m.channel])
else
debug("%s just left the network." % user)
end
end
:mode_change
This event gets triggered whenever modes in a channel or on the bot
directly change. Unlike events like :op
, this event is more
low-level, as the argument the handler gets passed is an array
describing every change.
:offline
This event is triggered when a monitored user goes offline.
One additional argument, the user going offline, gets passed to the handler.
:online
This event is triggered when a monitored user comes online.
One additional argument, the user coming online, gets passed to the handler.
:op
This event gets triggered when a user in a channel gets opped.
One additional argument, the user being opped, gets passed to the handler.
:owner
This event gets triggered when a user in a channel receives owner-status.
One additional argument, the user receiving owner-status, gets passed to the handler.
:message
The :message
event is triggered for messages directed at either a
channel or directly at the bot. It’s synonymous with :privmsg
.
:private
The :private
event is triggered for messages directly towarded at
the bot (think /query in traditional IRC clients).
See also the :channel
event.
:unaway
The :unaway
event is triggered when a user no longer is away. This
feature only works on networks implementing the “away-notify”
extension.
Example:
on :unaway do |m|
debug("User %s no longer is away." % m.user)
end
See also the :away
event.
:unban
The :unban
event is triggered when a user gets unbanned in a
channel.
One additional argument, a Ban object, gets passed to the handler.
:voice
This event gets triggered when a user in a channel gets voiced.
One additional argument, the user being voiced, gets passed to the handler.