From: Thorsten Kampe <thorsten@thorstenkampe.de>
To: zsh-users@sunsite.dk
Subject: Re: How to get faster completion if I make zsh assume what I've typed so far is correct?
Date: Wed, 7 Apr 2004 13:41:08 +0200 [thread overview]
Message-ID: <14f8etwgw10e8.dlg@thorstenkampe.de> (raw)
In-Reply-To: <4073DAE5.6040904@acm.org>
* paxunix (2004-04-07 12:41 +0100)
> I wrote:
>> Peter Stephenson wrote:
>>>paxunix wrote:
>>>>Why does zsh have to glob every directory along a pathname in order to
>>>>find completions within the final directory? For example, take this case:
>>>>
>>>>/one/two/three/four <TAB>
>>>>
>>>>If I set -x, the output after hitting TAB shows zsh retrieves all the
>>>>subdirectories within one, two, three and four.
>>>
>>>It's looking for /oneandabit/twoandabit/threeandabit/four... etc.
>>>
>>>I certainly agree it should be possible to turn this off but the
>>>function that implements this is very hairy and full of calls to poorly
>>>documented shell internals.
>>>
>>>The documentation in the zshcompsys manual page suggests setting
>>>
>>> zstyle ':completion:*:paths' accept-exact true
>>>
>>>or maybe (I'm not quite sure what the entry means and the implementation
>>>is obscure)
>>>
>>> zstyle ':completion:*:paths' accept-exact '*'
>>>
>> The latter works perfectly. The situation is even more pronounced on
>> zsh under Cygwin, where completing a path with
>> /cygdrive/<drive-letter> will cause your floppy drive to be accessed
>> every time you attempt a new completion. The accept-exact '*'
>> resolves this issue wonderfully. Many thanks!
>
> There are a couple of very annoying issues with this solution:
> ambiguous matches are not cycled through correctly and it is impossible
> to complete some pathnames.
That's why it's called "accept-exact", right?
> For example, if you have two directories:
>
> dir1
> dir1~
>
> Typing dir<TAB> will complete up to 'dir1' and (in my case) show dir1
> and dir1~ as possible completions. Successively hitting TAB will never
> cycle through to dir1~ - a trailing '/' is inserted after dir1 and zsh
> lists the contents of dir1 as possible completions. It appears that any
> common prefix to an initial path completion attempt causes completion to
> continue inside the first directory match. If it's between a directory
> and a filename with a common prefix, things work as they are supposed to.
>
> In case there is a style or option that is messing things up, here is my
> .compinstall:
>
> [...]
> zstyle ':completion:*:paths' accept-exact '*'
>
> and my setopt output:
Try "zstyle ':completion:*:paths' accept-exact continue"
Thorsten
next prev parent reply other threads:[~2004-04-07 11:41 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-23 16:26 paxunix
2004-03-23 16:56 ` Aidan Kehoe
2004-03-23 17:06 ` Peter Stephenson
2004-03-24 3:37 ` paxunix
2004-04-07 10:41 ` paxunix
2004-04-07 11:41 ` Thorsten Kampe [this message]
2004-04-07 12:32 ` Oliver Kiddle
2004-04-14 20:04 ` Peter Stephenson
2004-04-15 3:52 ` paxunix
2004-04-15 4:05 ` paxunix
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=14f8etwgw10e8.dlg@thorstenkampe.de \
--to=thorsten@thorstenkampe.de \
--cc=zsh-users@sunsite.dk \
/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).