On Sun, Nov 27, 2022 at 08:57:23AM -0500, Greg Wooledge wrote:
> On Sun, Nov 27, 2022 at 08:16:23AM +0100, to...@tuxteam.de wrote:
> > On Sat, Nov 26, 2022 at 11:00:07PM +0100, email.list...@gmail.com wrote:
> >
> > [...]
> >
> > > select(1, [0], NULL, [0], {tv_sec=0, tv_usec=500000}) = 0
> > ^
> >
> > This (nearly ;-) answers my question: it is waiting for half-a-second
> > on stdin, i.e. on you.
> >
> > You can probably speed things up by quickly hitting TAB again (no,
> > no, I'm not seriously proposing that as a "solution" to your problem,
> > but I've the hunch that this is intentional: something inserting that
> > delay before annoying you with early completions, in case you are
> > just in the middle of typing; I'd guess this "something" considers
> > TAB a possible part of the regular input and is giving you a chance
> > to type on: a classical misunderstanding between software and user).
>
> My instinct says the same.
>
> unicorn:/var/tmp/bash/bash-5.2/lib/readline$ grep 500 *.c
> bind.c: nval = 500;
> parens.c:static int _paren_blink_usec = 500000;
> readline.c:int _rl_keyseq_timeout = 500;Thanks for actually looking into the source... > unicorn:/var/tmp/bash/bash-5.2/lib/readline$ grep -B2 500 readline.c > /* Timeout (specified in milliseconds) when reading characters making up an > ambiguous multiple-key sequence */ > int _rl_keyseq_timeout = 500; > > If you type byte(s) that could be standalone characters, or which could > be the start of a bound sequence, readline will delay a little bit to > see if there are additional bytes to follow. > ... yes, this looks very promising. Cheers -- t
signature.asc
Description: PGP signature
