* Re: Compadd churning on matching specs
@ 2000-04-25 11:25 Sven Wischnowsky
0 siblings, 0 replies; 2+ messages in thread
From: Sven Wischnowsky @ 2000-04-25 11:25 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 2+ messages in thread
* Compadd churning on matching specs
@ 2000-04-25 7:52 Felix Rosencrantz
0 siblings, 0 replies; 2+ messages in thread
From: Felix Rosencrantz @ 2000-04-25 7:52 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2000-04-25 11:25 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-04-25 11:25 Compadd churning on matching specs Sven Wischnowsky
-- strict thread matches above, loose matches on Subject: below --
2000-04-25 7:52 Felix Rosencrantz
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).