* refs/remotes/tmux-openbsd/master:
build: don't exit
build: always attempt portable merge
build: capture openbsd-base before filtering
build: fetch cutover master before merge
Use _exit in child after fork, from Yayo Razo in GitHub issue 5376.
Add missing calloc check and use fatal. Prompted by a similar change from Yayo Razo.
actions: use published openbsd-git as base update
github actions: automate updates
Do not make pty fds blocking again until all the data has been consumed or control mode clients can get stuck, GitHub issue 5356 from Ben Maurer.
Add formats and events for OSC 133 commmands, as well as a -T flag to set-hook -B to only fire when the format is true.
Replace the notification system with events. Events can carry a payload of additional payload (to reduce problems with lifetime of objects) and are delivered to one or more event sinks. This is more powerful and reduces the complex dependencies between control mode and hooks. Events are now used for hooks, control mode notifications and for monitors (set-hook -B).
additional payload (to reduce problems with lifetime of objects) and are
delivered to one or more event sinks. This is more powerful and reduces the
complex dependencies between control mode and hooks. Events are now used for
hooks, control mode notifications and for monitors (set-hook -B).
wait-for can now wait for an event to fire (-E flag, with -F to for filter),
with -v to print the payload, as well as listing (-l) waiting clients on an
event and forcing one to wake (-w).
A few additional hooks are also now available (pane-created, pane-resized, etc)
and some of the existing ones have additional format variables available.
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.
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.
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.
much as before - buffers are automatically named "buffer0000",
"buffer0001" and so on and ordered as a stack. Buffers can be named
explicitly when creating ("loadb -b foo" etc) or renamed ("setb -b
buffer0000 -n foo"). If buffers are named explicitly, they are not
deleted when buffer-limit is reached. Diff from J Raynor.
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.
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.
Thomas Adam