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
