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

Reply via email to