Hi, 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.
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"' 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"' As with key-bindings, multiple commands can be bound with ";", but there can only ever be two hooks (before/after) per tmux command. 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. * 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. * 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. * We should presumably also think about how/if the notify() functions work with hooks as they could provide some contextual information to commands, although they seem limited to control mode at present, which is a shame. Any questions, please ask. Kindly, -- Thomas Adam Thomas Adam (1): Hook support: Proof-of-concept Makefile.am | 3 ++ cmd-set-hook.c | 90 +++++++++++++++++++++++++++++++++++++++++++ cmd-show-hooks.c | 62 ++++++++++++++++++++++++++++++ cmd.c | 70 +++++++++++++++++++++++++++++++++- hooks.c | 114 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ session.c | 2 + tmux.c | 2 + tmux.h | 23 +++++++++++ 8 files changed, 365 insertions(+), 1 deletion(-) create mode 100644 cmd-set-hook.c create mode 100644 cmd-show-hooks.c create mode 100644 hooks.c -- 1.7.11.4 ------------------------------------------------------------------------------ LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d _______________________________________________ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
