Re: [EPIC]windows / message hooks
And again... Now about ON message hooks. Some hooks, like alot of public_* hooks and channel_signoff are filtered agains current channel and sender channels, other hooks are common. Shouldn't it be more clean: either filtering are to be done by scripts or in ircclient core ? In last case there should be action_other, ctcp_other, etc_other - when channel (or general 'target') is not current, action_msg, ctcp_msg - when sender is not on channel it sends message to. and ever more: send_public_other, send_msg_other - when sending messages to not current channel/nick. ? What 'policy' says about it ? The special on hooks, such as /on public_other and so forth are a terrible blight on ircII and exist strictly for backwards compatability (ie, this is not a fight i want to pick right now). I *strenuously object* to adding more of them. I also object to the removal of any legacy /on's for backwards compatability's sake. Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
Re: [EPIC]windows / message hooks
And u still haven't said what u think should be added and what removed ?... Or i miss some idea ? :) I think no changes should be made. Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
Re: [EPIC]windows / message hooks
Would't it be fine to have hooks - for all numerics replies (by their RPL_names) or to group ERR_ replies into one hook ? - for each nonnumerics messages: PRIVMSG, NICK, JOIN, PART, etc - one for ctcp, with type as one of arg - for dcc For backwards compatability is it possible to generate/throw events in scripts ? qMax ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
Re: [EPIC]windows / message hooks
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
