From: Nikolai Weibull <now@disu.se>
To: Frank Terbeck <ft@bewatermyfriend.org>
Cc: Ramkumar Ramachandra <artagnon@gmail.com>, zsh-workers@zsh.org
Subject: Re: [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer
Date: Sat, 27 Apr 2013 10:56:20 +0200 [thread overview]
Message-ID: <CADdV=MsZCtr_D9O=ph+O142iLKDv2kvMkpRW8iVP8iP=CNHiXw@mail.gmail.com> (raw)
In-Reply-To: <87haiu2zwk.fsf@ft.bewatermyfriend.org>
On Thu, Apr 25, 2013 at 9:06 PM, Frank Terbeck <ft@bewatermyfriend.org> 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.
next prev parent reply other threads:[~2013-04-27 8:56 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-20 12:56 [PATCH 0/3] Completion/Unix/Command/_git: misc fixes Ramkumar Ramachandra
2013-04-20 12:56 ` [PATCH 1/3] Completion/Unix/Command/_git: add a couple of browsers Ramkumar Ramachandra
2013-04-20 12:56 ` [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer Ramkumar Ramachandra
2013-04-20 13:03 ` Nikolai Weibull
2013-04-20 15:05 ` Frank Terbeck
2013-04-20 17:13 ` Ramkumar Ramachandra
2013-04-20 17:35 ` Bart Schaefer
2013-04-20 17:50 ` Ramkumar Ramachandra
2013-04-25 12:42 ` Frank Terbeck
2013-04-25 13:11 ` Nikolai Weibull
2013-04-25 18:12 ` Ramkumar Ramachandra
2013-04-25 17:48 ` Ramkumar Ramachandra
2013-04-25 19:06 ` Frank Terbeck
2013-04-27 8:56 ` Nikolai Weibull [this message]
2013-04-27 9:01 ` Nikolai Weibull
2013-04-28 14:30 ` Nikolai Weibull
2013-05-11 16:55 ` Nikolai Weibull
2013-05-12 17:48 ` Peter Stephenson
2013-04-27 10:22 ` Ramkumar Ramachandra
2013-04-27 11:27 ` Frank Terbeck
2013-04-20 12:56 ` [PATCH 3/3] Completion/Unix/Command/_git: branch.*.pushremote, remote.pushdefault Ramkumar Ramachandra
2013-04-21 10:16 ` [PATCH 0/3] Completion/Unix/Command/_git: misc fixes Frank Terbeck
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='CADdV=MsZCtr_D9O=ph+O142iLKDv2kvMkpRW8iVP8iP=CNHiXw@mail.gmail.com' \
--to=now@disu.se \
--cc=artagnon@gmail.com \
--cc=ft@bewatermyfriend.org \
--cc=zsh-workers@zsh.org \
/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).