zsh-users
 help / color / mirror / code / Atom feed
From: frederik@ofb.net
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: Zsh Users <zsh-users@zsh.org>
Subject: Re: completion autolist has time-sensitive interface
Date: Wed, 15 Aug 2018 18:45:13 -0700	[thread overview]
Message-ID: <20180816014513.GE30438@ofb.net> (raw)
In-Reply-To: <CAH+w=7Z_swkvkJv97F0ULmzvZsDk-FZUSXNeSuV1bwa_Y44ofA@mail.gmail.com>

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


  reply	other threads:[~2018-08-16  1:45 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20180815061554epcas3p4806e2cb2444ee67f4cb404ed2957a750@epcas3p4.samsung.com>
     [not found] ` <20180815054958.GA27844@ofb.net>
     [not found]   ` <20180815083359eucas1p157426370c46cd6d59b96b8964f0445ce~LAcQObm1u2570325703eucas1p1b@eucas1p1.samsung.com>
2018-08-15 15:57     ` frederik
2018-08-15 17:54       ` Bart Schaefer
2018-08-16  1:45         ` frederik [this message]
2018-08-16  3:55           ` Eric Cook
2018-08-16 12:05             ` frederik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180816014513.GE30438@ofb.net \
    --to=frederik@ofb.net \
    --cc=schaefer@brasslantern.com \
    --cc=zsh-users@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).