When a CSI sequence (e.g. kitty keyboard ESC[118;5;3u) gets split across two stdin reads, the 10ms timeout flushes the incomplete prefix as an opaque "unknown" response instead of waiting for the final byte.
The timeout exists to detect lone ESC keypresses, but once we're in CSI state (ESC[ already seen), the sequence is unambiguous. We should keep waiting for the final byte rather than flushing on timeout.
This causes flaky input on Windows Terminal Preview where kitty key release events arrive split across reads.
Fix: Don't honor forceFlush in csi state in scanPending(). The sequence will either complete on the next read or get interrupted by a new ESC (already handled). Same applies to osc/dcs/apc.
When a CSI sequence (e.g. kitty keyboard
ESC[118;5;3u) gets split across two stdin reads, the 10ms timeout flushes the incomplete prefix as an opaque"unknown"response instead of waiting for the final byte.The timeout exists to detect lone ESC keypresses, but once we're in CSI state (
ESC[already seen), the sequence is unambiguous. We should keep waiting for the final byte rather than flushing on timeout.This causes flaky input on Windows Terminal Preview where kitty key release events arrive split across reads.
Fix: Don't honor
forceFlushincsistate inscanPending(). The sequence will either complete on the next read or get interrupted by a new ESC (already handled). Same applies toosc/dcs/apc.