On 2022-11-27 14:57, 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;
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.)
This is what my ~/.inputrc looks like
$include /etc/inputrc
$if mode=emacs
"\C-xc": copy-region-as-kill
"\C-xx": kill-region
"\C-ii": kill-whole-line
"\M-f": vi-backward-bigword
"\M-b": vi-forward-bigword
$endif
