on kick could be replaced by on before_kick and on kick could be emulated with a defer shook kick $* per default. That'd be backwards compatible and not add another on
//kreca On 9/1/06, Misha <[EMAIL PROTECTED]> wrote: > On 8/31/06, Stanislaw Halik <[EMAIL PROTECTED]> wrote: > > Hello, > > > > The behaviour of `/on kick' seems different than the rest of channel > > hooks and inadequate for some purposes. > > > > The hook is thrown after the KICK command is processed by the client, > > which means that in case we're the ones being kicked from the channel, > > its data is lost before we're able to react. This includes > > channel-to-window association, nicklist and possibly more. > > > > AFAIK, `/on kick' works this way because of autorejoin scripts, so they > > could `/join $2' and actually rejoin, without just getting the `You are > > now talking to channel #foo' message. > > > > My opinion is that these simple autorejoin scripts should adapt to more > > general /on behaviour (for instance, /defer'ing the /join command) > > instead of forcing `/on kick' to be insufficient for other purposes. > > > > What are your opinions? Should `/on kick' stay the way it is now, or > > should it be changed to work more similarly to other channel hooks? > > I faced with that in BlackJac's Intrepid script. winchan() function > can't get number of the window where you were kicked. > IMHO, the best way to resolve that problem - add new hook, something > like before_kick (name suggested by Jeremy), which will be thrown just > before channel information is deleted. > > Why do so? I think epic should give users right of choose what do they > want to do. There may be uncountable cases where user need only one > behaviour and other is unwanted. > _______________________________________________ > List mailing list > List@epicsol.org > http://epicsol.org/mailman/listinfo/list > _______________________________________________ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
