| Commit message (Collapse) | Author | Age |
|---|
| |\ |
|
| | | |
|
| |\| |
|
| | | |
|
| |\| |
|
| | |
| |
| |
| | |
has been respawned.
|
| |\| |
|
| | |
| |
| |
| | |
return NULL. GitHub issue 1547.
|
| |\| |
|
| | |
| |
| |
| | |
by Kristof Kovacs in GitHub issue 1186.
|
| |\| |
|
| | |
| |
| |
| |
| | |
correctly, so set it explicitly back to default (and the others for good
measure).
|
| |\|
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
cmd-pipe-pane.c
proc.c
tmux.c
window.c
|
| | |
| |
| |
| |
| |
| | |
event_reinit) - if the child gets a signal and fires the libevent signal
handler during this period it could write a signal into the parent's
signal pipe. GitHub issue 1001 from Aaron van Geffen.
|
| | | |
|
| |\| |
|
| | |
| |
| |
| | |
has been written to the pipe-pane event if there is one. GitHub issue 991.
|
| |\| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
and not have to wait for an update when they change pane, we allow
commands to run more than once a second if the expanded form
changes. Unfortunately this can mean them being run far too often
(pretty much continually) when multiple clients exist, because some
formats (including #D) will always differ between clients.
To avoid this, give each client its own tree of jobs which means that
the same command will be different instances for each client - similar
to how we have the tag to separate commands for different panes.
GitHub issue 889; test case reported by Paul Johnson.
|
| |\| |
|
| | |
| |
| |
| |
| |
| | |
CMD_FIND_* flags in the cmd_entry and call it for the command. Commands
with special requirements call it themselves and update the target for
hooks to use.
|
| |\| |
|
| | |
| |
| |
| |
| |
| | |
jobs, this means that if the same job is used for different windows or
panes (for example in pane-border-format), it will be run separately for
each pane.
|
| |\| |
|
| | | |
|
| |\| |
|
| | |
| |
| |
| | |
handling.
|
| |\|
| |
| |
| |
| |
| | |
Conflicts:
format.c
osdep-openbsd.c
|
| | | |
|
| |\| |
|
| | | |
|
| |\| |
|
| | |
| |
| |
| | |
using an enum and simplify the parsing code.
|
| |\| |
|
| | |
| |
| |
| | |
about the order.
|
| |\| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
the state (client, session, winlink, pane) for it it before entering the
command. Each command provides some flags that tell the prepare step
what it is expecting.
This is a requirement for having hooks on commands (for example, if you
hook "select-window -t1:2", the hook command should to operate on window
1:2 not whatever it thinks is the current window), and should allow some
other target improvements.
The old cmd_find_* functions remain for the moment but that layer will
be dropped later.
Joint work with Thomas Adam.
|
| |\| |
|
| | |
| |
| |
| | |
command name (will also be used for more later).
|
| |\| |
|
| | | |
|
| |\| |
|
| | | |
|
| |/ |
|
| |
|
|
| |
command execution is not needed.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
directly with a helper function in the cmd_entry, include a table of
bind-key commands and pass them through the command parser and a
temporary cmd_q.
As well as being smaller, this will allow default bindings to be command
sequences which will probably be needed soon.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commands and allow a command to block execution of subsequent
commands. This allows run-shell and if-shell to be synchronous which has
been much requested.
Each client has a default command queue and commands are consumed one at
a time from it. A command may suspend execution from the queue by
returning CMD_RETURN_WAIT and then resume it by calling cmd_continue() -
for example run-shell does this from the callback that is fired after
the job is freed.
When the command queue becomes empty, command clients are automatically
exited (unless attaching). A callback is also fired - this is used for
nested commands in, for example, if-shell which can block execution of
the client's cmdq until a new cmdq becomes empty.
Also merge all the old error/info/print functions together and lose the
old curclient/cmdclient distinction - a cmdq is bound to one client (or
none if in the configuration file), this is a command client if
c->session is NULL otherwise an attached client.
|
| |
|
|
|
| |
cmd_find_client to tell it whether or not to show errors, sometimes it's
needed and sometimes not.
|
