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

[Nikolai Weibull <now@xxxxxxx>]

On Thu, Apr 25, 2013 at 9:06 PM, Frank Terbeck <ft@xxxxxxxxxxxxxxxxxxx> wrote:
> Ramkumar Ramachandra wrote:
> [...]
>> Now, I'm a shell-scripting beginner and do not have the expertise to
>> fully evaluate zsh's completer versus git.git's completer.  From my
>> untrained eyes, zsh's completer looks more complete and comprehensive
>> but git.git's completer looks terse and less intimidating.  There is
>> definitely a noticeable difference in speed: git.git's completer is
>> much faster, and there's no doubt about that.

> It's also more up to date. And the reason for that is simple. Git is
> still moving fairly fast, and the _git completion is basically written
> and maintained by one guy. One. A few people tried to chip in every once
> in a while (myself included), but since nobody of those people really
> follows git's development too closely that's a battle you cannot win.

Yes, this is definitely a problem, and something I can’t really assist
with at the moment.

> The thing with previous encounters (I'm recollecting from memory here,
> and I hope I'm not too inaccurate) is that Felipe pretty much demanded,
> not asked - demanded, that all features that slowed the completion down
> should be removed, not be made optional - removed, even though the
> original author (Nikolai) put a lot of time into realising those
> features.

Felipe seems to apply his bullying tactics to any project that doesn’t
do as he wishes, see, for example,
http://redmine.yorba.org/issues/6813

>> I want to work on the completer without fundamentally difficult
>> problems (because I can't fix those fundamentally difficult problems).
>
> Maybe Nikolai would be willing to try and tackle the more fundamental
> problems.

I sadly don’t have the time.

>> Speed seems to be a big pain point in zsh's completer, and that seems
>> to be a very difficult problem to solve (I saw a few list emails about
>> it).  However, it looks like we can gradually make git.git's completer
>> more comprehensive.

> This thing with speed is this: Yes, _git is slower than the bash
> completion. But - at least when I last looked - _git will provide much
> more useful suggestions depending on the context of the cursor position.
> And I - personally - am happy to wait for, say, a second if that means I
> can save several seconds selecting the right choice. However, some
> completions are too slow on really large repositories. That would be a
> useful area to improve - maybe make the slow smartness optional? I don't
> know.

Definitely, and it should already be possible.  You can override many
of the more complex helpers by overriding the commands that _git calls
to generate results.

I think the first thing we need to do is identify the pain points.

For example

  % git add ^I

takes close to a second to complete in a clean git.git.  I don’t quite
see why that is, but git ls-files takes almost 0.1 second to run and
seems to be the main problem.  Hard to get around using git ls-files,
though.

I see (via _complete_debug) that _git-add gets called twice because I have

zstyle ':completion:*' matcher-list 'm:{[:lower:]}={[:upper:]}'
'r:|[:.,_-]=** r:|=**'

in my .zshrc.

I guess that gitcdup and gitprefix can be cached in __git_files, which
would shave off about 0.1 seconds per call to _git-add.

Anyway, I mostly use Magit now, so I might not be the right maintainer anymore.