control.ControlSender.mute_pane

A control client is sent the output of every pane in the session it attached to, which is one window's worth or a hundred. One pane running yes moves more than 20 MB in two seconds, and a client tmux judges five minutes behind is disconnected with too far behind, so discarding the unwanted panes on arrival is not enough.

Muting a pane that does not exist is not an error; tmux ignores an unresolvable id here.

Below crate::since::CONTROL_PANE_OFF this pauses the pane rather than taking it out of the stream, because taking it out crashes the server. tmux keeps reading the pane's pty either way, discarding what this connection does not want; a paused pane costs only that connection's own back-pressure, and ControlEvents sees Event::Paused for it.

At or above that release, taking the pane out of the stream also stops tmux reading its pty at all -- for every attached client, not only this connection, and for a one-shot reader such as capture-pane too -- until Self::unmute_pane or Self::resume_pane turns it back on. A human attached to the same pane sees it stop updating, and the pane's own program can block on write once the kernel's pty buffer fills. What arrives once resumed is therefore a backlog, not a gap: see Self::unmute_pane .

Errors

Returns an error when the connection has closed or tmux refuses the stream change.