Compadd churning on matching specs

[Felix Rosencrantz <f_rosencrantz@xxxxxxxxx>]

Here is a possible problem with compadd and matching.  I was trying to complete
the pathname of the completion function directory in a zsh release tree.
Completion goes quickly until trying to complete the last component of the
path, then there is a big pause. Starting with the path (I add the build date
to the version):
        cd /drive2/tools/zsh/share/zsh/3.1.7-pre-1-000421/ work

This directory has only one sub-directory "functions", so it would
seem that completion should go quickly.  I hit TAB, and there is a big
pause. I turned on xtrace and the problem occurs around:

_path_files:548> compadd -Qf -J -default- -X %B---- directory%b -M
m:{a-zA-Z}={A
-Za-z}  r:|[.,_-]=* r:|[A-Z0-9]=* -p
/drive2/tools/zsh/share/zsh/3.1.7-pre-1-000
421/ -W /drive2/tools/zsh/share/zsh/3.1.7-pre-1-000421/ -M r:|/=* r:|=* -
functi
ons

A quick check with the debugger shows the pause occurs in bin_compadd():
complete.c:562         dm = addmatches(&dat, argv);

Looking a little further, there seems to be a large number of calls
to match_str, but it is using the path supplied with the -p/-W flags
for matching.  (The debugger output is slightly different from the example
above, I typed fun to start the completion.)

#15 0xe8fe8 in match_str (
    l=0x252960 "/drive2/tools/zsh/share/zsh/3.1.7-pre-1-000421/fun",
    w=0x2529a0 "/drive2/tools/zsh/share/zsh/3.1.7-pre-1-000421/",
    bpp=0xefff7cf0, bc=0, rwlp=0x0, sfx=0, test=0, part=1) at compmatch.c:548

With all the matching specifications that I provided and the ones
_path_files provided, this causes match_str to chew for a while.  This
seems wasteful, since we already know that the first part of the path is
fully specified.  Would it be possible to just do matching on the last
part of the path, where "function" should be added?

-FR.     

__________________________________________________
Do You Yahoo!?
Send online invitations with Yahoo! Invites.
http://invites.yahoo.com