* Re: completion autolist has time-sensitive interface [not found] ` <20180815083359eucas1p157426370c46cd6d59b96b8964f0445ce~LAcQObm1u2570325703eucas1p1b@eucas1p1.samsung.com> @ 2018-08-15 15:57 ` frederik 2018-08-15 17:54 ` Bart Schaefer 0 siblings, 1 reply; 5+ messages in thread From: frederik @ 2018-08-15 15:57 UTC (permalink / raw) To: Peter Stephenson, zsh-users; +Cc: Zsh hackers list 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: completion autolist has time-sensitive interface 2018-08-15 15:57 ` completion autolist has time-sensitive interface frederik @ 2018-08-15 17:54 ` Bart Schaefer 2018-08-16 1:45 ` frederik 0 siblings, 1 reply; 5+ messages in thread From: Bart Schaefer @ 2018-08-15 17:54 UTC (permalink / raw) To: Frederick Eaton; +Cc: Zsh Users 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: completion autolist has time-sensitive interface 2018-08-15 17:54 ` Bart Schaefer @ 2018-08-16 1:45 ` frederik 2018-08-16 3:55 ` Eric Cook 0 siblings, 1 reply; 5+ messages in thread From: frederik @ 2018-08-16 1:45 UTC (permalink / raw) To: Bart Schaefer; +Cc: Zsh Users 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: completion autolist has time-sensitive interface 2018-08-16 1:45 ` frederik @ 2018-08-16 3:55 ` Eric Cook 2018-08-16 12:05 ` frederik 0 siblings, 1 reply; 5+ messages in thread From: Eric Cook @ 2018-08-16 3:55 UTC (permalink / raw) To: zsh-users 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: completion autolist has time-sensitive interface 2018-08-16 3:55 ` Eric Cook @ 2018-08-16 12:05 ` frederik 0 siblings, 0 replies; 5+ messages in thread From: frederik @ 2018-08-16 12:05 UTC (permalink / raw) To: Eric Cook; +Cc: zsh-users 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2018-08-16 12:05 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CGME20180815061554epcas3p4806e2cb2444ee67f4cb404ed2957a750@epcas3p4.samsung.com> [not found] ` <20180815054958.GA27844@ofb.net> [not found] ` <20180815083359eucas1p157426370c46cd6d59b96b8964f0445ce~LAcQObm1u2570325703eucas1p1b@eucas1p1.samsung.com> 2018-08-15 15:57 ` completion autolist has time-sensitive interface frederik 2018-08-15 17:54 ` Bart Schaefer 2018-08-16 1:45 ` frederik 2018-08-16 3:55 ` Eric Cook 2018-08-16 12:05 ` frederik
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).