Why shouldn't /close trigger ON CLOSE? I don't really see a reason.
to remain consistent with the standard that it's adhered to ever since its introduction. i'm not saying there shouldn't be a comfortable way to intercept ALL window closures, i just think it ill-advised to make such changes willy nilly. it's a shame that on OPEN/CLOSE didn't exhibit this fuller functionality to begin with; scripters have now become used to and perhaps, at times, rely on present behaviour.
I don't really buy overriding builtin /commands to be a viable alternative.
it isn't! in cases like these, scripters should endeavour to include the necessary handling with the portions of their scripts that use the /query, /close etc. commands. even though it can be out of their control, this is the sensible approach to the problem, and the one that should be mentioned first and foremost.
Actually, by your reasoning, /sockopen should not trigger ON SOCKOPEN.
no no, the key difference with on SOCKCLOSE is that it is triggered in response to external stimuli whereas those other events trigger only as a direct result of their respective /sock* commands. there are only a handful of events that are appropriate to the discussion (ones that can conceivably trigger in direct response to a command or from an external message); on SOCKCLOSE was the first that came to mind :P
I don't see the issue. "query blocker" scripts tend to be in the form:
ON ^*:OPEN:?:*:if ($nick == foo) halt
sometimes, sometimes not. what you have there is just about the same as adding foo!*@* to your ignore list for private messages. a more common example is something similar to:
on ^*:open:?:*:%q = $nick : $1- | .timerq 1 0 $eval(%q = $input(Accept pm? %q, y), 0) | .timerq -e | if (!%q) halt
to suddenly change on OPEN in the proposed way would be undesirable for the user of such a script, don't you agree?
a more pragmatic approach would be to introduce a new event prefix to have on OPEN/CLOSE trigger in response to commands, as well as what they currently do:
on ~*:OPEN:?:*:{ ; triggers for all query window openings }
as such, compatibility with older versions is fully preserved
