On Thu, Nov 08, 2012 at 04:33:37AM +0000, Ben Boeckel wrote:
> 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.
I don't want this because many hooks will not have a before/after, they
will just be. Also I don't like pre/post.
>
> > 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?
This is a reasonable idea.
>
> > 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?
Yes these will be added too.
>
> > 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
------------------------------------------------------------------------------
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
