>Would't it be fine to have hooks
>- for all numerics replies (by their RPL_names)
> or to group ERR_ replies into one hook ?
Who would be responsible for mapping numerics to RPL_names? What happens
when a server uses a custom RPL_name that epic doesn't know about? This
is not really feasable.
>- for each nonnumerics messages:
> PRIVMSG, NICK, JOIN, PART, etc
There are already more than enough /on's for these types of messages.
We don't need to make it even more complicated for scripters to keep
track of what is going on. /on public_other and /on msg_group really
shouldn't exist if there were any justice in the world.
>- one for ctcp, with type as one of arg
>- for dcc
>
>For backwards compatability is it possible
>to generate/throw events in scripts ?
Again -- adding more /on's doesn't solve any problems, it only makes it
worse. That's why we have the patterns argument. What is the fucntional
difference between
/on ctcp_version "from to argument" {...}
and
/on ctcp "from to VERSION argument" {...}
except a few characters transposed?
I oppose adding gratuitous /on's that are already covered by other /on's.
I oppose removing legacy /on's for backwards compatability reasons only.
Jeremy
_______________________________________________
List mailing list
[EMAIL PROTECTED]
http://epicsol.org/mailman/listinfo/list
