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

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

[paxunix]

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.  I would like zsh to 
only bother globbing in four to find the files that I'm looking for--it 
should assume that whatever I've currently typed is correct and it ONLY 
needs to look in four--there is no need for it to know anything about 
the contents of one, two or three.  Is there a style setting or an 
option that I can use to do that?  If two, three and four are NFS, it 
can often slow down completion a lot--particularly if there are a lot of 
files in them.

-- 
Shawn Halpenny

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

[Aidan Kehoe]

 Ar an 23ú lá de mí 3, scríobh paxunix :

 > If I set -x, the output after hitting TAB shows zsh retrieves all the 
 > subdirectories within one, two, three and four.  I would like zsh to 
 > only bother globbing in four to find the files that I'm looking for--it 
 > should assume that whatever I've currently typed is correct and it ONLY 
 > needs to look in four--there is no need for it to know anything about 
 > the contents of one, two or three.

What if one, two or three doesn't exist?

-- 
I don't care if it rains or freezes/'Long as I got my Plastic Jesus
Riding on the dashboard of my car.

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

[Peter Stephenson]

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.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

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

[paxunix]

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

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!

-- 
Shawn Halpenny

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

[paxunix]

[-- 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

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

[Thorsten Kampe]

* 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

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

[Oliver Kiddle]

Thorsten Kampe wrote:
> * paxunix (2004-04-07 12:41 +0100)

> >> 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!

For just resolving the /cygdrive/<drive-letter> problem, it might be
better to use something like: accept-exact '[acdef]'
just list all your drive letters. That will limit the scope of the
style more than '*'.

> > 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 because it is enabling accept-exact for the last component and
not just the earlier path components.

I don't know of any way to get this to work properly (short of digging
into the C source for compfiles). It really ought to be possible to
disable the partial completion.

> Try "zstyle ':completion:*:paths' accept-exact continue"

That won't help. It would just affect directories named `continue'. The
value `continue' is a feature of the _expand completer so should be used
with a context like ':completion:*:expand:*'. It allows both completions
and expansions to be offered in the case of exact ambiguous matches.

Oliver

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

[Peter Stephenson]

Oliver Kiddle wrote:
> > > 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 because it is enabling accept-exact for the last component and
> not just the earlier path components.
> 
> I don't know of any way to get this to work properly (short of digging
> into the C source for compfiles). It really ought to be possible to
> disable the partial completion.

Both ought to be possible: failing to accept an exact completion early
in the path can cause big problems, and there may well be times you
don't want partial completion at all.  But finding out how to do it
might be tricky.

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>
Work: pws@csr.com
Web: http://www.pwstephenson.fsnet.co.uk

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

[paxunix]

paxunix wrote:

[ using  zstyle ':completion:*:paths' accept-exact '*' to avoid partial 
completion globs on directory elements ]

> 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.

On a hunch, I changed the '*' to '*(N)', so my resulting zstyle line became:

zstyle ':completion:*:paths' accept-exact '*(N)'

and so far this seems to do precisely what I want, without the above 
annoyances.  I especially noticed the difference when completing 
dotfiles in my home directory.  Without '*(N)', try:

ls ~/.<TAB>

and notice that none of the dotfiles are given as possible completions.  
Instead you get a trailing slash appended and then non-dotfile 
completions from the home directory.  With '*(N)', this works as expected.

-- 
Shawn Halpenny

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

[paxunix]

paxunix wrote:

> paxunix wrote:
>
> [ using  zstyle ':completion:*:paths' accept-exact '*' to avoid 
> partial completion globs on directory elements ]
>
>> 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.
>
>
> On a hunch, I changed the '*' to '*(N)', so my resulting zstyle line 
> became:
>
> zstyle ':completion:*:paths' accept-exact '*(N)'
>
> and so far this seems to do precisely what I want, without the above 
> annoyances.  I especially noticed the difference when completing 
> dotfiles in my home directory.  Without '*(N)', try:
>
> ls ~/.<TAB>
>
> and notice that none of the dotfiles are given as possible 
> completions.  Instead you get a trailing slash appended and then 
> non-dotfile completions from the home directory.  With '*(N)', this 
> works as expected.

Argh--spoke too soon.  I had two windows open at the same time with each 
of the zstyle settings, and must have used the wrong one.  My mistake.

--SH