From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16078 invoked from network); 23 May 2000 12:36:29 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 23 May 2000 12:36:29 -0000 Received: (qmail 10231 invoked by alias); 23 May 2000 12:36:15 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 11528 Received: (qmail 10222 invoked from network); 23 May 2000 12:36:09 -0000 Date: Tue, 23 May 2000 14:33:37 +0200 (MET DST) Message-Id: <200005231233.OAA23987@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: Peter Stephenson's message of Tue, 23 May 2000 12:44:18 +0100 Subject: Re: complete (real C) tags Peter Stephenson wrote: > ... > > Finally, I've noticed it's several *times* slower for a long tags list when > going through _main_complete (see Sven's patch for _complete_tag in 11459) > rather than just compadd, so I'm very tempted just to miss that out --- try > it with a full `etags -t **/*.[ch]' TAGS file for zsh: I get less than a > second with just compadd, something like five seconds with _main_complete > (on a Sun Enterprise server, too). I suppose the problem is the huge array > being constantly set and restored as it passes through the shell functions > --- it may not have very much to do with completion as such, although I > think that saves and restores some of its state when calling functions, > too. Only the $words, $PREFIX, $etc. parameters. But yes, I noticed that, too. I see two `solutions' (until we have a better parameter code, although I'm not sure how much that could be improved, all those "$@"...): - Suggest that at least in cases where huge lists of matches can be generated, the matches are generated as late as possible, using utility functions. The problem here is that to make it really fast, _wanted would have to be called with the name of the utility function and that only generates the matches and calls compadd with the arguments it got from _wantd/_all_labels. For some of the utility functions we have, this would mean to split them in two. - Allow some option or whatever to _wanted and friends which says that the command strings should be expanded at the very end, so that we only pass the string '$(sed...)' around. - This could also be done by a new utility function which would be called instead of compadd and itself expands its arguments and call compadd with the result. Actually, I've been tempted from the beginning to allow compadd to get the matches not only from its positional parameters, but also from arrays whose names are given as arguments. That would allow us to stuff the matches into some array and then call: foo=(...) _wanted ... compadd -a foo or some such. That could be combined with the `...expands its arguments'. I.e., we could add a utility function (`_compadd' ? >:->) that only calls compadd, but allows taking the matches from arrays, or from the keys of named associations or that (all this selected via options) expands its arguments to get the matches. But I still think it would be nice to put that in the C-code for compadd, to avoid even the final expansion of the array. And of course, with something like these tags, I would use caching, at least if the stat module is available so that we can compare file modification times. That enhancement to compadd and/or the compadd-wrapper function... any opinions from anyone? Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de