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
[email protected]
https://lists.sourceforge.net/lists/listinfo/tmux-users
