mirror of
https://github.com/junegunn/fzf.git
synced 2026-10-07 20:54:41 +08:00
Junegunn Choi
d2a99bb929
fzf consumed only the part of a sequence it recognized, and the rest was typed into the query. CTRL-A sent as \e[97;5u became "97;5u", and CTRL-F sent as \e[70;5u fired Home before typing ";5u". A BEL-terminated OSC reply also aborted fzf, because the BEL that followed the typed payload was read as CTRL-G. Frame CSI and SS3 by their parameter and final byte ranges, OSC, DCS and APC by their terminator. Drop the whole frame when the parser does not recognize it, or recognizes only a prefix of it. Take the second-chance read only when the sequence at the start of the buffer is the only one and is unfinished. Otherwise it blocked until the next key, holding back what followed, CTRL-G included. Telling a terminal's sequence from an ALT key is the hard part, so these keep what the parser made of them: - An unterminated sequence, since that is how ALT-[, ALT-O, ALT-], ALT-P and ALT-_ arrive - A CSI or SS3 of four bytes or fewer. It could be an ALT key and typed text, and rxvt sends keys of that size fzf does not know, such as \e[3^ - A final byte after an intermediate $. rxvt ends keys with $, as in \e[7$ and \e[23$, so the byte after it is the next key - A string sequence whose payload does not start like a reply: digits and ';' for OSC, '>|', '!|', '[01]$r' or '[01]+r' for DCS, 'G' and a key for APC - SOS and PM, which nothing sends Within a string, an ESC ends it and introduces a sequence of its own, and only OSC ends with BEL. The read loop does not wait for a string terminator: that held ALT-], ALT-P and ALT-_ for ESCDELAY and let typed bytes pile up until they looked like a sequence.