Re: How to get faster completion if I make zsh assume what I've typed so far is correct?

[paxunix <paxunix@acm.org>]

[-- Attachment #1: Type: text/plain, Size: 3052 bytes --]

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 '*'
>>
>>If neither works, I would definitely interpret that as a bug.
>>
>>I'm afraid vagueness is the order of the day since the author hasn't
>>been seen in these parts for ages.  Maybe Oliver knows more.
>>
> 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!

Following up to myself--

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.  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:*' completer _complete _expand
zstyle ':completion:*' format 'Completing %d...'
zstyle ':completion:*' insert-unambiguous true
zstyle ':completion:*' list-colors ${(s.:.)LS_COLORS}
zstyle ':completion:*' matcher-list 'm:{a-zA-Z}={A-Za-z}'
zstyle :compinstall filename "$HOME//.compinstall"
zstyle ':completion:*:paths' accept-exact '*'

and my setopt output:

noalwayslastprompt
alwaystoend
autopushd
nobeep
completeinword
extendedglob
extendedhistory
globcomplete
histfindnodups
histignorealldups
histreduceblanks
histsavenodups
interactive
interactivecomments
nolistambiguous
nolistbeep
login
monitor
nonomatch
nopromptcr
promptsubst
pushdignoredups
pushdminus
rmstarsilent
sharehistory
shinstdin
typesetsilent
zle

Any ideas appreciated.

-- 
Shawn Halpenny