What ships
A deliberate stderr-handling semantic for the three
`display_message` wrappers (`Server.display_message`,
`Window.display_message`, `Pane.display_message`). Likely one of:
- Version-gated raise via `has_gte_version("3.3")` (warn on tmux
3.2a where control-mode dispatch is unreliable, raise on 3.3+)
- A per-call `raise_on_stderr: bool = False` kwarg so callers
opt in to escalation
- A permanent `warnings.warn` contract with no escalation path
beyond `warnings.catch_warnings(filterwarnings("error"))`
The choice will be driven by observed user pain — what kinds of
stderr tmux actually emits in practice, and what shape of escalation
callers reach for.
Problem solved
Callers need a way to distinguish "tmux rejected my format string"
from "tmux returned empty legitimately." #672 softened the wrappers
to `warnings.warn` because raising had two issues:
- tmux 3.2a's control-mode dispatch path can fail silently (no
stderr emitted), so raising on stderr doesn't actually catch
that bug — it just made other tests skip with
`has_gte_version("3.3")` workarounds.
- tmux uses stderr for both genuine errors and informational
messages, and the right escalation depends on tmux version and
call shape.
The warn-soften gives users access to the stderr without losing the
return value. This issue tracks the eventual deliberate contract.
Why this is its own shipment
The right contract depends on what kinds of stderr tmux actually
emits in practice, which is observable only after the wrappers see
real use in 0.57.0. Holding the decision until that data exists
prevents locking in a contract that the next release has to break.
Acceptance criteria
Current state on master (post-0.57.0)
All three wrappers emit `warnings.warn("display-message: ")`
with `stacklevel=2`. Callers can already escalate via:
```python
import warnings
with warnings.catch_warnings():
warnings.filterwarnings("error", category=UserWarning)
result = pane.display_message("#{pane_id}", get_text=True)
```
The question this issue resolves is whether that escalation path
suffices, or whether the wrappers should grow a more deliberate API.
Refs
What ships
A deliberate stderr-handling semantic for the three
`display_message` wrappers (`Server.display_message`,
`Window.display_message`, `Pane.display_message`). Likely one of:
3.2a where control-mode dispatch is unreliable, raise on 3.3+)
opt in to escalation
beyond `warnings.catch_warnings(filterwarnings("error"))`
The choice will be driven by observed user pain — what kinds of
stderr tmux actually emits in practice, and what shape of escalation
callers reach for.
Problem solved
Callers need a way to distinguish "tmux rejected my format string"
from "tmux returned empty legitimately." #672 softened the wrappers
to `warnings.warn` because raising had two issues:
stderr emitted), so raising on stderr doesn't actually catch
that bug — it just made other tests skip with
`has_gte_version("3.3")` workarounds.
messages, and the right escalation depends on tmux version and
call shape.
The warn-soften gives users access to the stderr without losing the
return value. This issue tracks the eventual deliberate contract.
Why this is its own shipment
The right contract depends on what kinds of stderr tmux actually
emits in practice, which is observable only after the wrappers see
real use in 0.57.0. Holding the decision until that data exists
prevents locking in a contract that the next release has to break.
Acceptance criteria
tmux 3.4+ behaves according to the chosen contract on both
success and stderr paths
`display_message` tests
exception (or rationale for permanent warn)
Current state on master (post-0.57.0)
All three wrappers emit `warnings.warn("display-message: ")`
with `stacklevel=2`. Callers can already escalate via:
```python
import warnings
with warnings.catch_warnings():
warnings.filterwarnings("error", category=UserWarning)
result = pane.display_message("#{pane_id}", get_text=True)
```
The question this issue resolves is whether that escalation path
suffices, or whether the wrappers should grow a more deliberate API.
Refs