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.