Re: complete (real C) tags

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxxxxx