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
v1.24: remove wait_for_pane_idle — it timed out on every Claude paste
The v1.23 idea was: detect Claude generating via the live `↓ N tokens`
indicator, hold the dispatch until idle, dispatch on timeout. The
detector matched any visible scrollback line containing `<digit>
tokens` — chat history, release notes, "Saved 200 tokens", etc. —
so in practice it timed out on every press into a Claude pane and
added the full timeout (5 s default, was 30 s in early v1.23) as
pure latency before dispatching anyway.
Confirmed in journalctl on this box, two consecutive presses on
pane=%41:
INFO Claude TUI busy — holding paste until idle pane="%41"
WARN wait_for_pane_idle: timed out, dispatching anyway timeout_ms=5000
INFO dispatched image paste ms_idle_wait=5097 ms_total=5116
INFO Claude TUI busy — holding paste until idle pane="%41" <- replay
WARN wait_for_pane_idle: timed out, dispatching anyway timeout_ms=5000
INFO dispatched image paste ms_idle_wait=5145 ms_total=5168
Two presses → ten seconds of guaranteed hang, then the bytes
dispatched in the same state they would have dispatched in
immediately. Net value of the wait: zero.
Removed:
- tmux::wait_for_pane_idle / claude_is_busy / line_has_token_counter
- PaneSnapshot::is_claude
- FLASHPASTE_PANE_IDLE_TIMEOUT_MS env knob
- ms_idle_wait phase timing field from paste.rs
The honest contract is: paste fires immediately; if Claude is
mid-generation and drops the \026 byte, the user retries. One
retry << 5 s of guaranteed hang.
Kept: paste_in_flight + pending_paste dedup. With the wait gone
its window is ~10–20 ms (the dispatch itself), still useful for
absorbing rapid double-clicks on the right-click → Paste menu so
Claude sees one \026 instead of two.
Pane-aware replay (bundled): state.rs adds
`pending_pane: Mutex<Option<String>>` and ipc.rs reads it on
replay, so a press to pane B during pane A's in-flight dispatch
gets replayed to B (not A). Watcher had caught this as
"absorbed-press pane=%38 → replay pane=%41 (wrong pane)".
Misc ipc.rs: demote `Broken pipe (os error 32)` from WARN to
DEBUG on the accept path. It's the trigger's 150 ms read timeout
closing the socket before the queued-paste reply lands — expected
behaviour, not a bug, but it was dominating the WARN stream.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
-`wait_for_pane_idle` in `rs/flashpasted/src/tmux.rs` (and the `claude_is_busy` / `line_has_token_counter` helpers + the `FLASHPASTE_PANE_IDLE_TIMEOUT_MS` env knob in `paste.rs`). The v1.23 idea was to detect Claude generating via the live `↓ N tokens` indicator and hold the dispatch until idle; empirically the detector matched any scrollback line containing `<digit> tokens` (chat history, release notes, "Saved 200 tokens", etc.), so it timed out on every press into a Claude pane and added the full timeout (5 s default after the v1.23 30 s → 5 s tweak) as pure latency. Confirmed in journalctl: `ms_idle_wait=5097`, `ms_idle_wait=5145` back-to-back on `pane=%41`. Dispatches now fire immediately; if the TUI drops the byte the user retries, which is far cheaper than 5 s of guaranteed hang.
34
+
35
+
### Kept
36
+
37
+
- The `paste_in_flight` + `pending_paste` dedup in `state.rs` / `ipc.rs` stays. With the wait gone its window shrinks from "up to 30 s" to "~10–20 ms" (just the dispatch itself) but it's still useful for absorbing a rapid double-click on the right-click → Paste menu so Claude sees one `\026` instead of two.
38
+
39
+
### Changed
40
+
41
+
- The in-flight dedup is now **pane-aware**. `state.rs` adds a `pending_pane: Mutex<Option<String>>` that records the most recent absorbed pane id; the replay dispatch reads it and targets the saved pane instead of always replaying to the pane the initial dispatch was running on. Watcher had caught the cross-pane bug as "absorbed-press pane=%38 → replay pane=%41 (wrong pane)."
42
+
-`ipc.rs` demotes `Broken pipe (os error 32)` on the IPC accept path from `WARN` to `DEBUG`. That's the trigger's 150 ms read timeout closing the socket before we finish writing the queued-paste reply — expected behaviour, not a bug, but it was polluting the WARN stream.
0 commit comments