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. > 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? > 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? > 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