From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4168 invoked by alias); 16 Aug 2018 01:45:24 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: List-Unsubscribe: X-Seq: 23585 Received: (qmail 13238 invoked by uid 1010); 16 Aug 2018 01:45:24 -0000 X-Qmail-Scanner-Diagnostics: from icgriddb04.seas.upenn.edu by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(158.130.57.72):SA:0(-1.9/5.0):. Processed in 1.647794 secs); 16 Aug 2018 01:45:24 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham autolearn_force=no version=3.4.1 X-Envelope-From: frederik@ofb.net X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Date: Wed, 15 Aug 2018 18:45:13 -0700 From: frederik@ofb.net To: Bart Schaefer Cc: Zsh Users Subject: Re: completion autolist has time-sensitive interface Message-ID: <20180816014513.GE30438@ofb.net> Reply-To: frederik@ofb.net References: <20180815054958.GA27844@ofb.net> <20180815083359eucas1p157426370c46cd6d59b96b8964f0445ce~LAcQObm1u2570325703eucas1p1b@eucas1p1.samsung.com> <20180815155700.GD30438@ofb.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: 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