Re: [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer

[Peter Stephenson <p.w.stephenson@ntlworld.com>]

On Sat, 11 May 2013 18:55:58 +0200
Nikolai Weibull <now@disu.se> wrote:
> On Sun, Apr 28, 2013 at 4:30 PM, Nikolai Weibull <now@disu.se> wrote:
> > On Sat, Apr 27, 2013 at 10:56 AM, Nikolai Weibull <now@disu.se> wrote:
> >
> >> I think the first thing we need to do is identify the pain points.
> >
> > I would really appreciate some input on this.  What commands are slow,
> > where, and with which repositories?
> 
> OK, so we’ve gotten no responses on this.  Shall I take it that there
> are no commands for which completion is slow?

The problem seemed to be with certain archives.  It looks like the
people with those archives aren't to be found in these parts...  Nothing
with the zsh archive is unusably slow, certainly, and that's the only
one I use with any frequency.  Completion after "git show" takes a
couple of seconds on this machine (a few years old now), but I've got no
feeling for how that's likely to scale.  It's significantly slower than
"git add", for example, so maybe the place to look is for time taken in
git commands.  However, like you I'm largely in the dark about "real"
problems.

I have been wondering about setting up (zsh) tag ordering so I don't get offered
things I don't use much, such as git tags, but the capabilities for that are
already there.  It probably doesn't make sense to limit things by default.
If we wanted to make it easier for people to do this it ought to be something
generic, not git-specific --- e.g. it might be nice to be able to hit a key
in a given context so that instead of completing it showed you the possible
tags and prompted you to decide what order you'd like them offering in.
(Unless you can already and I missed it.)

Just some random thoughts on the subject so it doesn't go completely quiet...

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/