Re: Speaking of slow completion ...

[Sven Wischnowsky <wischnow@informatik.hu-berlin.de>]

Bart Schaefer wrote:

> Have any of you with sourceforge logins tried completing `cd /h/g/z'?
> 
> It's *minutes* before something comes back, the first time.  Thereafter
> the filesystem info is cached (by the linux kernel, not in zsh) and it
> goes down to only several seconds. (E.g. if you were to log in and try it
> *right now*, it'd be fairly fast, because *I* just waited the minutes for
> the FS cache to load.)
> 
> Any ideas on optimizing _path_files for directories with LOTS of subdirs?

I have been thinking about _path_files quite often. For one thing I
still think if any completion function gets C-code support, than it
should be _path_files, probably the function that gets called more
often than every other function. C-support should help us avoid all
that array-handling.

Another thing is the globbing. Because of possible `*' match specs,
_path_files has to always get all files (or directories), which is
slowish, of course. Even using the first character of the $PREFIX in
the globbing could speed things up significantly, but if that is one
of the anchors in a `r:|...=*' pattern, the result could be wrong.

Hm, maybe we should add C-support for getting `special' characters
with respect to the currently used match specs and _path_files could
then use the part of the $PREFIX (and $SUFFIX) that doesn't contain
such characters.

Another (more interesting) thing is trying to glob more than one
directory level at once. There's a problem with the expand styel,
though.


Felix Rosencrantz wrote:

> Something I suggested in workers/9630 would be to have a style that caused 
> _path_files to basically do stats (-d/-f) on the leading portion of a path that
> is to be completed.  If the leading part exists, don't attempt to do any
> completion on that part of the path, you've got what you want.  Or check for
> existence before attempting to glob a name.

Seem like I didn't fully grok that at that time. Yes, indeed, doesn't
even sound hard to implement.

> ...
> 
> Also, on a side note, I think there might be a bug in compadd (possibly
> matching) that causes it to get in a bad state if an interrupt is sent while it
> is working.  I typically want to interrupt in situations when completion is
> slow.  Completion works, but matching seems to have some problems.  (I know,
> you probably want some those helpful details...)

Indeed, I do.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de