completion autolist has time-sensitive interface

completion autolist has time-sensitive interface

[frederik]

Dear Zsh Hackers,

Sometimes completion is so laggy on my system that when I press TAB
after e.g. "man perl", nothing seems to happen. So I press it again.
Still nothing happens. Completion seems broken.

Took me a while to figure out the problem. It's related to "setopt
autolist" (which is on by default for me?).

What happens is that if I just press TAB once, e.g. after "man perl",
there is a one-second delay and a prompt "zsh: do you wish to see all
201 possibilities (51 lines)?". At this point I can press TAB again,
which is equivalent to "y" I guess, and I see a list of completions.

However, if I press TAB twice quickly in succession then I see no
list, it is exactly as if there are no completions at all. (Actually
if the prompt is at the bottom of the screen, I get a newline) I find
it confusing that the completion interface would be time-sensitive in
this manner. Why TAB-delay-TAB would behave differently from TAB-TAB.
Usually everything I do on the terminal has the property that it
doesn't matter how fast or slow I type, it's only the order of the
keys that's important...

Someone on #zsh (user "jp" - thanks) recommended "bashautolist" but it
has the same problem, only after three TABs.

Thanks,

Frederick

Re: completion autolist has time-sensitive interface

[Peter Stephenson]

On Tue, 14 Aug 2018 22:49:58 -0700
<frederik@ofb.net> wrote:

> Dear Zsh Hackers,
> 
> Sometimes completion is so laggy on my system that when I press TAB
> after e.g. "man perl", nothing seems to happen. So I press it again.
> Still nothing happens. Completion seems broken.
> 
> Took me a while to figure out the problem. It's related to "setopt
> autolist" (which is on by default for me?).
> 
> What happens is that if I just press TAB once, e.g. after "man perl",
> there is a one-second delay and a prompt "zsh: do you wish to see all
> 201 possibilities (51 lines)?". At this point I can press TAB again,
> which is equivalent to "y" I guess, and I see a list of completions.

One possibility would be if you had (presumably inadvertently) a
key with TAB as a prefix.  Then it would delay to see if you're
going to type the full key stroke, and only execute the TAB binding
if you didn't.  It's not very likely, but it's the best I can think
of.

If you run

bindkey | grep '\^I'

you'll probably see something like

"^I" complete-word
"^[^I" self-insert-unmeta

where the second isn't relevant as there's an ESC in front.  If you
see something else starting with ^I that's a problem.

BTW this is probably more suitable for zsh-users where the larger
audience is more likely to have seen something similar.

pws

Re: completion autolist has time-sensitive interface

[frederik]

I'm adding zsh-users at Peter's suggestion.

Thanks in advance.

On Wed, Aug 15, 2018 at 09:33:58AM +0100, Peter Stephenson wrote:
> On Tue, 14 Aug 2018 22:49:58 -0700
> <frederik@ofb.net> wrote:
> 
> > Dear Zsh Hackers,
> > 
> > Sometimes completion is so laggy on my system that when I press TAB
> > after e.g. "man perl", nothing seems to happen. So I press it again.
> > Still nothing happens. Completion seems broken.
> > 
> > Took me a while to figure out the problem. It's related to "setopt
> > autolist" (which is on by default for me?).
> > 
> > What happens is that if I just press TAB once, e.g. after "man perl",
> > there is a one-second delay and a prompt "zsh: do you wish to see all
> > 201 possibilities (51 lines)?". At this point I can press TAB again,
> > which is equivalent to "y" I guess, and I see a list of completions.
> > 
> > However, if I press TAB twice quickly in succession then I see no
> > list, it is exactly as if there are no completions at all. (Actually
> > if the prompt is at the bottom of the screen, I get a newline) I find
> > it confusing that the completion interface would be time-sensitive in
> > this manner. Why TAB-delay-TAB would behave differently from TAB-TAB.
> > Usually everything I do on the terminal has the property that it
> > doesn't matter how fast or slow I type, it's only the order of the
> > keys that's important...
> 
> One possibility would be if you had (presumably inadvertently) a
> key with TAB as a prefix.  Then it would delay to see if you're
> going to type the full key stroke, and only execute the TAB binding
> if you didn't.  It's not very likely, but it's the best I can think
> of.
> 
> If you run
> 
> bindkey | grep '\^I'
> 
> you'll probably see something like
> 
> "^I" complete-word
> "^[^I" self-insert-unmeta
> 
> where the second isn't relevant as there's an ESC in front.  If you
> see something else starting with ^I that's a problem.
> 
> BTW this is probably more suitable for zsh-users where the larger
> audience is more likely to have seen something similar.

Thanks. When I run `bindkey | grep '\^I'` it shows me the same thing
that you see.

Maybe it will be hard for others to reproduce this as a slow computer
is needed. Or maybe if there were some way to run Zsh with input
provided programmatically, like `echo "man perl\t\t" | zsh`...

Frederick