|
From: | Yuriy Ershov |
Subject: | Re: [Bug-readline] {forward,reverse}-search-history binding bug |
Date: | Sun, 12 Nov 2017 18:49:50 +1100 |
On 10/27/17 12:55 AM, Yuriy Ershov wrote:
> Ah, it seems I understand what is happening!
> In *-search-history mode there is no ANY delay allowed for ESC key.
Not quite. This comment is appropriate:
/* ESC still terminates the search, but if there is pending
input or if input arrives within 0.1 seconds (on systems
with select(2)) it is used as a prefix character
with rl_execute_next. WATCH OUT FOR THIS! This is intended
to allow the arrow keys to be used like ^F and ^B are used
to terminate the search and execute the movement command.
XXX - since _rl_input_available depends on the application-
settable keyboard timeout value, this could alternatively
use _rl_input_queued(100000) */
> It looks like in *-search-history mode readline is "previewing" the next
> input char and prefers to escape back to "normal" mode if there is anything
> unusual.
If there is more input or if input arrives within a tenth of a second.
> This is the way the Up and Down keys work.
> Also, if *-search-history is bound to a key starting with ESC, it detects
> the next ESC key and bails out to the normal mode, leaving that ESC in the
> input queue.
Only if ESC is in the set of characters that terminates the search. If you
remove ESC from the value of the readline `isearch-terminators' variable,
you should have better luck.
> Then readline reads the sequence: ah, there's a *-search-history command,
> let's do the search. But because it has just entered the mode, the buffer
> is empty.
Right.
> Does it look like the truth?
Pretty close. A nice job of investigation.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU address@hidden http://cnswww.cns.cwru.edu/~chet/
[Prev in Thread] | Current Thread | [Next in Thread] |