From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
Subject: Re: complete (real C) tags
Date: Tue, 23 May 2000 14:33:37 +0200 (MET DST) [thread overview]
Message-ID: <200005231233.OAA23987@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: Peter Stephenson's message of Tue, 23 May 2000 12:44:18 +0100
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
next reply other threads:[~2000-05-23 12:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-05-23 12:33 Sven Wischnowsky [this message]
2000-05-23 12:56 ` Peter Stephenson
-- strict thread matches above, loose matches on Subject: below --
2000-05-17 14:54 Peter Stephenson
2000-05-17 16:57 ` Bart Schaefer
2000-05-23 11:44 ` Peter Stephenson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200005231233.OAA23987@beta.informatik.hu-berlin.de \
--to=wischnow@informatik.hu-berlin.de \
--cc=zsh-workers@sunsite.auc.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).