On Thu, Nov 08, 2012 at 04:33:37AM +0000, Ben Boeckel wrote: > Could a `-w` flag for 'when' the hook is to be called could be done > instead of embedding it into the name? I'd also prefer pre/post over > before/after, but it's not a big deal.
I don't care about the name, but I think before/after is better understood than pre/post is. As for a "-w" flag, the point of before/after is explicit, and whilst I originally had the idea of separating the two out, having discussed this with Nicholas, we went with before/after -- and making the hook name the determining factor in when such hooks get run. > > This adds two hooks to the global hooks -- which are inherited by all > > sessions. Per-sessions hooks are supported too: > > > > set-hook -nfoo -n'after-new-window' 'run "notify-send new window..."' > > set-hook -nfoo -n'before-new-window' 'display-message creating new window"' > > Could a `run-hook` command be added so that session hooks can chain-call the > global hooks manually? I'd really want to avoid doing this. As with the way options work now, session options inherit global ones, and can be overriden there. "Chaining" on hooks does not make sense. More than one command per hook, sure, but that then means overriding this in each session when that's needed. That also keeps things simpler. > > As with key-bindings, multiple commands can be bound with ";", but there can > > only ever be two hooks (before/after) per tmux command. > > With the Python stuff and a dynamic command table, custom aliases could > be added to get multiple hooks. That loses support for scripts for the > most part though (no generic script is going to call `tmux > my-new-window` by default. They're two very different things though. The python bindings are far too invasive, and do not allow for generic actions to run, which is the point of this patch. > What about hooks for things like when a pane/window/session ends? No hooks for those, but see my previous reply about how the notify() functions have to work with hooks. > > * At present, there's no information passed down to commands about the hook > > being run. For example if I had this: > > > > set-hook -nfoo -n'after-new-window' 'run "my_shell_script.sh"' > > > > we should provide some information such as the session name, etc., so that > > external commands can manipulate what ever they need to in context. > > For commands such as set-environment or set-option, passing the values > that caused the hook to be called would be nice to have. That ability > would be worth losing before/after hook calls, IMO. Maybe having both > would be nice (-w <before|after|during>)? Not sure how that would work > if 'during' hooks have a different API than 'before' or 'after' hooks. Forget "during". That makes no sense to me at all. :) Passing options needs to be as loose and having it tied to the context is fine, which is why using the format_tree mechanism to provide this makes sense. If a format is specified to a hook which is outside its content, it's simply not expanded. This also allows for people to get as many options in context as they like. > Would a non-zero exit status from a 'before' ('during' might be too > late in the general case) hook be able to cancel the command? Maybe a Yes it would cancel the command. -- Thomas Adam ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov _______________________________________________ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users