Chet, you are absolutely right: binding to a sequence without ESC works well. But also I am sure there is no delay after initial ESC in the sequence. Just because I am using a local terminal, the whole key sequence must be instantly appearing in the buffer. In theory, there might be a casual delay just because of unexpected context switch or network disruptions but that can't be happening consistently every time. So there may be an error waiting for that 0.1 sec timeout.
Took a quick look at the source: the default keyseq-timeout = 500ms (_rl_keyseq_timeout in C). And this is exactly what I see in my local readline vars. Is it the same number used to timeout the ESC key? I hardly believe I am that slow at typing :) As I can see there is a quite complex state machine inside so I can't quickly work out what is happening in there but I imagine there may be some missing/dropped state that gets checked in _rl_isearch_dispatch (or maybe somewhere else). This is just a guess though. Cheers, Yury On Fri, Oct 27, 2017 at 1:21 AM, Chet Ramey <[email protected]> wrote: > On 10/26/17 4:21 AM, Yuriy Ershov wrote: > > Hi, > > > > TL;DR: binding of reverse-search-history and forward-search-history to a > > combination of more than one key leads to wrong behavior: the search > string > > gets reset. > > Does this happen with characters other than ESC? ESC is special: it > cancels the search unless additional input is received within 0.1 seconds. > This is what allows the arrow keys to work while searching. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRU [email protected] http://cnswww.cns.cwru.edu/~ > chet/ >
_______________________________________________ Bug-readline mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-readline
