On Thu, Nov 08, 2012 at 04:33:37AM +0000, Ben Boeckel wrote: > On Sun, Nov 04, 2012 at 01:22:50 GMT, Thomas Adam wrote: > > I'm attaching one patch for now -- an idea for how hook support in tmux > > might work. There's no documentation yet as I envisage things still in a > > state of flux. > > Nice :) . > > > All commands that tmux recognise have the ability to have hooks attached to > > them. These hooks in turn can run other tmux commands (and hence run-shell > > for external commands). Hooks come in two forms: 'after' and 'before'; > > that is to say, hooks can run before or after a given tmux command. > > > > Here's an example: > > > > set-hook -g -n'after-new-window' 'run "notify-send new window..."' > > set-hook -g -n'before-new-window' 'display-message creating new window"' > > 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 want this because many hooks will not have a before/after, they will just be. Also I don't like pre/post. > > > 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? This is a reasonable idea. > > > 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. > > What about hooks for things like when a pane/window/session ends? Yes these will be added too. > > > So some questions (in no particular order): > > > > * The hook-name matters; at the moment the implementation assumes > > cmd->entry->name and NOT cmd->entry->alias -- should both be checked? > > That might mean though one can have a hook with both "new-window" and > > "neww" defined, which is bad. > > +1 for full name only. > > > * Per-session hooks are only ever enacted if the command sent to them comes > > from the client attached to that session. So for example, if I have this > > binding: > > > > set-hook -nfoo -n'after-new-window' 'run "notify-send new window..."' > > > > and I run the following from either outside of an attached tmux session, > > or some other session which ISN'T "foo": > > > > tmux new-window -tfoo > > > > then I will never see the specified hook run. > > > > This is because the cmd_ctx used to run hooks only knows about the context > > of where the command was run *from*. I'm wondering how much of a drawback > > this will be, or whether this makes sense? I'm not sure it does though > > because if I manipulate a session from some other session which has hooks, > > I'd expect those hooks to run. > > > > To "fix" this, we would need to change where and how hooks are run from, > > much like the notify_() hooks do now, but there would then be no > > before/after mechanism. > > Hrm...I think I'd prefer the target's hooks run instead of depending on > the context. I can forsee questions such as "why aren't my hooks > running?" with this behavior if it's not made perfectly obvious from the > documentation. > > > * 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. > > 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 > flag for `set-hook` to do so would be useful? One potential problem I > can think of with this behavior is how it might confuse a control-mode > client. > > An `-n` flag to the main tmux executable to suppress all hook support (?? > l?? `git commit -n`) might be worthwhile as well. > > -- Ben > > > ------------------------------------------------------------------------------ > 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 ------------------------------------------------------------------------------ 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