Re: [Bug-readline] {forward,reverse}-search-history binding bug

[Chet Ramey]

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/