fix(tui): use shared paste burst interval on Windows#18914
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: fe37f770bf
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // Windows terminals (especially VS Code integrated terminal) deliver paste events | ||
| // more slowly than native terminals, so we use a higher threshold there. | ||
| #[cfg(not(windows))] | ||
| const PASTE_BURST_CHAR_INTERVAL: Duration = Duration::from_millis(8); |
There was a problem hiding this comment.
Reinstate Windows-specific burst interval fallback
Using a single 8ms PASTE_BURST_CHAR_INTERVAL on Windows can reintroduce split/auto-submitted multiline pastes on slower terminal paths. In note_plain_char, gaps above this value reset consecutive_plain_char_burst, so burst mode never activates and Enter suppression may not apply. This regresses the prior Windows safety behavior for environments that still deliver paste chars with >8ms jitter.
Useful? React with 👍 / 👎.
Summary
Fixes #11678 by removing the Windows-specific
PASTE_BURST_CHAR_INTERVALoverride. Windows now uses the same8mspaste-burst character interval as macOS and Linux, which removes the extra per-character hold that made fast typing and key repeat feel delayed on Windows.The paste-burst heuristic itself is unchanged, and the Windows-specific active idle timeout remains in place. This PR only restores the shared character-to-character burst threshold that decides whether adjacent plain character events are part of a paste.
Motivation
PR #9348 raised the Windows character interval from
8msto30msto protect the multiline paste behavior tracked in #2137, where pasted newlines could be interpreted as submits in Windows terminals. That fixed the paste failure, but it also made ordinary typing visibly laggy because the TUI waits briefly before flushing a single typed character while it checks whether a paste burst is forming.The deployed behavior here is to remove that Windows-only delay and return to the cross-platform threshold. Manual Windows validation of the critical VS Code integrated terminal path shows multiline paste still works with the final
8msvalue, including testing on VS Code1.107.0.Testing
cargo test -p codex-tui8msinterval