On Sun, Nov 04, 2012 at 01:22:50AM +0000, Thomas Adam wrote:
> 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.

No, just the name. before-new-window, after-new-window etc.

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

Hmm. Perhaps having per-session hooks doesn't make much sense.

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

Run the command through as a format?

> 
> * 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

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

Reply via email to