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;
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.
Normally this wouldn't happen on a tab, because you wouldn't have a bound
sequence that begins with a tab. So, this makes me wonder what custom
bindings the OP has got in their ~/.inputrc or similar files. (The fact
that it only happens on the regular user account, and not on root, points
toward it being configured in the HOME directory, not system-wide.)
