Skip to content

Conversation

@joshka-oai
Copy link
Collaborator

User-facing symptom: On terminals that deliver pastes as rapid
KeyCode::Char/Enter streams (notably Windows), paste-burst transient state
can leak into the next input. Users can see Enter insert a newline when
they meant to submit, or see characters appear late / handled through the
wrong path.

System problem: PasteBurst is time-based. Clearing only the
classification window (e.g. via clear_window_after_non_char()) can erase
last_plain_char_time without emitting buffered text. If a buffer is still
non-empty after that, flush_if_due() no longer has a timeout clock to
flush against, so the buffer can get "stuck" until another plain char
arrives.

This was surfaced while adding deterministic regression tests for
paste-burst behavior.

Fix: when disabling burst detection, defuse any in-flight burst state:
flush held/buffered text through handle_paste() (so it follows normal
paste integration), then clear timing and Enter suppression.

Document the rationale inline and update docs/tui-chat-composer.md so
"disable_paste_burst" matches the actual behavior.

@joshka-oai joshka-oai force-pushed the joshka/paste-burst-fix branch from 3b57330 to f8b8fae Compare January 13, 2026 20:44
@joshka-oai joshka-oai force-pushed the joshka/paste-burst-tests branch from b504bed to 1ca7c58 Compare January 13, 2026 20:45
Base automatically changed from joshka/paste-burst-tests to main January 13, 2026 21:55
Copy link
Collaborator

@dylan-hurd-oai dylan-hurd-oai left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the cleanup here!

User-facing symptom: On terminals that deliver pastes as rapid
KeyCode::Char/Enter streams (notably Windows), paste-burst transient state
can leak into the next input. Users can see Enter insert a newline when
they meant to submit, or see characters appear late / handled through the
wrong path.

System problem: PasteBurst is time-based. Clearing only the
classification window (e.g. via clear_window_after_non_char()) can erase
last_plain_char_time without emitting buffered text. If a buffer is still
non-empty after that, flush_if_due() no longer has a timeout clock to
flush against, so the buffer can get "stuck" until another plain char
arrives.

This was surfaced while adding deterministic regression tests for
paste-burst behavior.

Fix: when disabling burst detection, defuse any in-flight burst state:
flush held/buffered text through handle_paste() (so it follows normal
paste integration), then clear timing and Enter suppression.

Document the rationale inline and update docs/tui-chat-composer.md so
"disable_paste_burst" matches the actual behavior.
@joshka-oai joshka-oai force-pushed the joshka/paste-burst-fix branch from f8b8fae to 2c24c0c Compare January 14, 2026 00:45
@joshka-oai joshka-oai enabled auto-merge (squash) January 14, 2026 00:46
@joshka-oai joshka-oai merged commit ce49e92 into main Jan 14, 2026
51 of 53 checks passed
@joshka-oai joshka-oai deleted the joshka/paste-burst-fix branch January 14, 2026 01:42
@github-actions github-actions bot locked and limited conversation to collaborators Jan 14, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants