Plan.run_over_control_mode
Run this plan over an open control-mode connection.
Source and package
- Qualified name
-
libtmux::plan:: Plan:: run _over _control _mode - Module
- plan
- Declared in
Plan- Package
- libtmux
- Source
- crates/libtmux/src/plan/run.rs
- #[cfg(feature = "control-mode")] impl Plan pub async fn run_over_control_mode( &self, sender: &crate::
control:: , ) -> Result<PlanControl Sender Result , Error> -
Description#
Control mode is the one transport that separates how many commands from how many processes: every operation is its own protocol block over one connection, so a plan costs one process however long it is and every operation still reports its own outcome. That is the combination a subprocess cannot offer -- there, sharing an invocation is what buys the process back, and it is exactly what costs the attribution.
There is no planner argument because there is nothing to trade: blocks are per command already.
Errors
Returns an error when the connection is closed, a command cannot be written, a slot dependency is invalid, or a creating operation does not return valid IDs, or a layout is invalid. Validation happens before the first recorded command. Version-sensitive layouts may query metadata. A command tmux refuses is reported in the
PlanResult.Layouts are checked against the connected daemon's version before any operation runs. Classic layouts also require enough cells for the panes created by preceding operations.
A plan holding a
super::ops::Pausefails withcrate::ControlModeErrorKind::BlockingCommandbefore anything is sent: tmux answers a delayedrun-shellon a connection at once and holds the next command instead, so the pause would report done before it was.Cancel safety
The effect can be partial, as for
Self::run(): steps already sent stay done, and the result naming them is lost with the future.- Parameters
tmux command#
The tmux commands behind run_over_control_mode.
capture-pane (the plan has a capture-pane step) kill-pane (the plan has a kill-pane step) kill-window (the plan has a kill-window step) new-session (the plan has a new-session step) new-window (the plan has a new-window step) rename-window (the plan has a rename-window step) select-layout (the plan has a select-layout step) select-pane (the plan has a select-pane step) select-window (the plan has a select-window step) send-keys (the plan has a send-keys step) set-environment (the plan has a set-environment step) set-option (the plan has a set-option step) split-window (the plan has a split-window step) tmux C API#
The C declarations in tmux that implement these commands.
cmd_capture_pane_entry cmd_capture_pane_exec cmd_kill_pane_entry cmd_kill_pane_exec cmd_kill_window_entry cmd_kill_window_exec cmd_new_session_entry cmd_new_session_exec cmd_new_window_entry cmd_new_window_exec cmd_rename_window_entry cmd_rename_window_exec cmd_select_layout_entry cmd_select_layout_exec cmd_select_pane_entry cmd_select_pane_exec cmd_select_window_entry cmd_select_window_exec cmd_send_keys_entry cmd_send_keys_exec cmd_set_environment_entry cmd_set_environment_exec cmd_set_option_entry cmd_set_option_exec cmd_split_window_entry cmd_split_window_exec Each path starts at a function a command runs, which is degree 1. The degree counts steps from there along the path, and each step is a call or a reference: degree 2 is reached from that function, degree 3 from the next, and so on.
Create a session and its first pane
- 1
cmd_new_session_exec - calls → 2
spawn_window - calls → 3
spawn_pane - calls → 4
window_add_pane - calls → 5
window_pane_create
Split a window
- 1
cmd_split_window_exec - references → 2
spawn_pane - calls → 3
window_add_pane - calls → 4
window_pane_create
Guides#
Pages that discuss run_over_control_mode.