Re: completion autolist has time-sensitive interface

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

Re: completion autolist has time-sensitive interface

[Bart Schaefer]

On Tue, Aug 14, 2018 at 10:49 PM,  <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.
>
> 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.

The delay is almost certainly the time required to generate the 201
possibilities rather than any "intentional" pause that zsh is doing.

Yes, at that particular prompt TAB and y/Y are equivalent, also ctrl-C
and ctrl-D (eof) and n/N are equivalent.

But there's more going on than that.  Before displaying the prompt,
zsh checks to see whether you have already typed something else
(typeahead) and if you have, it assumes you decided to disambiguate
the input further, so it skips printing the prompt and proceeds as if
you had answered "n".  So by pressing the second TAB while zsh is
still working on the set of completion for the menu, you have told the
shell you don't want to wait for the menu and it should simply
proceed.

> 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)

The faster you press the two TABs, the more likely you are to trigger
the typeahead detection.

> 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.

Back in the day, a lot of people would automatically muscle-memory
whack the tab key after typing part of a word, realize they didn't
mean to, and keep typing more of the word.  They were annoyed when the
shell ate part of their continued typing as the answer to the prompt,
leaving them with a word with one missing letter in the middle, so the
shell was changed to not do that.  This is also why pressing a second
TAB when the prompt does appear is treated as yes.

Re: completion autolist has time-sensitive interface

[frederik]

Thanks Bart.

> The delay is almost certainly the time required to generate the 201
> possibilities rather than any "intentional" pause that zsh is doing.

Yeah I wasn't suggesting that, my goodness.

> Yes, at that particular prompt TAB and y/Y are equivalent, also ctrl-C
> and ctrl-D (eof) and n/N are equivalent.
> 
> But there's more going on than that.  Before displaying the prompt,
> zsh checks to see whether you have already typed something else
> (typeahead) and if you have, it assumes you decided to disambiguate
> the input further, so it skips printing the prompt and proceeds as if
> you had answered "n".  So by pressing the second TAB while zsh is
> still working on the set of completion for the menu, you have told the
> shell you don't want to wait for the menu and it should simply
> proceed.
> 
> > 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)
> 
> The faster you press the two TABs, the more likely you are to trigger
> the typeahead detection.
> 
> > 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.
> 
> Back in the day, a lot of people would automatically muscle-memory
> whack the tab key after typing part of a word, realize they didn't
> mean to, and keep typing more of the word.  They were annoyed when the
> shell ate part of their continued typing as the answer to the prompt,
> leaving them with a word with one missing letter in the middle, so the
> shell was changed to not do that.  This is also why pressing a second
> TAB when the prompt does appear is treated as yes.

Interesting! I wonder if some workaround could be devised, either
showing a "..." to indicate that the shell is busy coming up with
completions, or not eating the typeahead when it consists of TABs.

There seems to be a lot of history here, anyway, thanks for explaining
what was going on.

By the way where do we control the number of completions which
triggers the "do you wish to see ..." prompt to appear?

Frederick

Re: completion autolist has time-sensitive interface

[Eric Cook]

On 08/15/2018 09:45 PM, frederik@ofb.net wrote:

> Interesting! I wonder if some workaround could be devised, either
> showing a "..." to indicate that the shell is busy coming up with
> completions, or not eating the typeahead when it consists of TABs.
> 
zstyle ':completion:*' show-completer true
may be what you want

Re: completion autolist has time-sensitive interface

[frederik]

On Wed, Aug 15, 2018 at 11:55:23PM -0400, Eric Cook wrote:
> On 08/15/2018 09:45 PM, frederik@ofb.net wrote:
> 
> > Interesting! I wonder if some workaround could be devised, either
> > showing a "..." to indicate that the shell is busy coming up with
> > completions, or not eating the typeahead when it consists of TABs.
> > 
> zstyle ':completion:*' show-completer true
> may be what you want

Thank you, indeed that fixes the problem for me. Now if I can figure
out how to get a better message than

    Trying completion for :completion::complete::

(... looks like I have to modify Completion/Base/Core/_main_complete?)

Thanks,

Frederick