Re: Question on filename completion

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On May 18, 10:53pm, Gowtham M wrote:
}
} When I hit tab at
} zsh> ls /some/path/to/something/761/xyz/_  # Tab is hit when cursor is at _
} 
} zsh spends a lot of time in stat64()ing all the directories from
} /some/path/to/something/0 to /some/path/to/something/9999
} 
} I do not understand why this is required to complete the filename
} after /some/path/to/something/761/xyz

This is _path_files at work.  Try typing

    zsh> ls /s/p/t/s<TAB>

and you'll find that it gets competed to

    zsh> ls /some/path/to/something/

On any given completion attempt, _path_files doesn't know whether any
path component might be only part of a directory name which, if it were
completed, would lead to additional matches among the sub-directories,
etc.  So it re-scans the whole hierarchy.

One way to prevent this from happening for hierarchies that you know
to be very broad is:

  zstyle ':completion:*' preserve-prefix '/some/path/to/something/*/'

That's not really the intended use of preserve-prefix but it has the
desired effect.  Note that preserve-prefix is a single string, not a
list of patterns (too bad, really) so if you want to use it for more
than one pattern, you have to construct the alternatives yourself:

  zstyle ':completion:*' preserve-prefix \
      '(/|?:|/some/path/to/something/*|/another/large/dir/*)/'

The preserve-prefix pattern is matched against a string, not against
files on disk, so it can have slashes inside the parens and cannot
use glob qualifiers that test file attributes.