Compadd churning on matching specs

Compadd churning on matching specs

[Felix Rosencrantz]

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

Re: Compadd churning on matching specs

[Sven Wischnowsky]

Felix Rosencrantz wrote:

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

No. At least, not really. The `problem' is that match_str() does more
than just check if the match matches the stuff on the line. It also
builds the mystical cline lists which contain the information we need
when building the unambiguous string.

I always wanted to see if and how I could make matching faster... maybe
now that enough people have started using match specs it is the time
to try. I'll need some time for this, though, I'm hoping to be able to 
replace some of the matching attempts with strcmp() and splitting the
string into parts. Dunno how well this will work, though.


When using match specs, it is often a good idea to give an empty
string as the first value to the matcher-list style. As Peter said, it 
reduces the number of surprising match results, but it also makes the
first attempt faster for most of the common cases.

Bye
 Sven


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