You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As libtmux has evolved with the 0.57.0 "Neo" ORM parity, we've solved the N+1 problem for object hydration. However, synchronizing with terminal output still largely relies on client-side loop polling via capture_pane().
We propose introducing a two-tier waiter system modeled after the patterns battle-tested in libtmux-mcp. This brings "Wait, Don't Poll" semantics natively to libtmux.
When observing third-party output (where we can't inject a signal), we must poll. However, naive capture_pane loops often match stale screen paint. We need Absolute Grid Anchoring.
The Concept: At entry, snapshot the grid's absolute baseline (history_size + cursor_y). On each tick, capture only the rows below this absolute anchor to ensure we strictly match new text.
libtmux-mcp Prior Art: See pane_tools/wait.py for the anchor math and scrollback limit protections.
tmux Internals: This approach is grounded in how tmux defines the grid (see format_cb_history_bytes and format_cb_history_size in format.c at 3.2a). It ensures compatibility with grid_collect_history and clear-history shifts.
Proposed API:
# Under the hood, this will use Neo-style batch hydration # to fetch `#{history_size}|#{cursor_y}` in a single IPC turn.pane.wait_for_text("READY", timeout=8.0)
3. Future Scope: Control Mode Listener
A long-term architectural goal could involve spawning a background tmux -C client (as currently used in libtmux testing via ControlMode) to listen for %output or %pane-mode-changed streams, offering a completely event-driven API.
Activity