From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22773 invoked by alias); 25 Apr 2013 19:20:36 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 31331 Received: (qmail 18409 invoked from network); 25 Apr 2013 19:20:33 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE, SPF_HELO_PASS autolearn=ham version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at bewatermyfriend.org does not designate permitted sender hosts) From: Frank Terbeck To: Ramkumar Ramachandra Cc: zsh-workers@zsh.org, Nikolai Weibull Subject: Re: [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer In-Reply-To: (Ramkumar Ramachandra's message of "Thu, 25 Apr 2013 23:18:42 +0530") References: <1366462573-15545-1-git-send-email-artagnon@gmail.com> <1366462573-15545-3-git-send-email-artagnon@gmail.com> <87mwsm3ho5.fsf@ft.bewatermyfriend.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) Date: Thu, 25 Apr 2013 21:06:35 +0200 Message-ID: <87haiu2zwk.fsf@ft.bewatermyfriend.org> MIME-Version: 1.0 Content-Type: text/plain X-Df-Sender: [pbs]NDMwNDQ0 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 definitely is. It does a bit less though. 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. 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. He was also completely against putting time into finding the root cause of the problems, so that maybe the additional features could be kept and sped up - even though people told him, they liked those features and they didn't see the impact (because they only get really annoyingly relevant on large repositories like the linux kernel, which not everybody works on - there is also not a lot of negative feedback on these mailing lists or the freenode IRC channel about the _git completion). Long story short, Felipe's rather hostile tone got him a pretty short-spoken final reply from Nikolai, which he now shows off to anyone who does or doesn't ask. This whole _git business is rather off-putting and I'd like to avoid putting any more time and energy into any "politics" that are involved on either side. This is no fun. I don't want to get steamed up about things like this. > 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. > 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. > That's all I really have. Can you help me out, and tell me more? The one thing, that _git lacks the most is able bodies. People, who are willing to update the different sub-command handlers to the current git development. Command --options, git-config options, new sub-commands. You name it. Nikolai can't do it all on his own, unless _git is his only project in life, which it is not. > I would really like for us all to work on one completer. Well, the bash and zsh completion mechanisms are pretty different. There are some features that zsh provides, that you just can't map to bash. That makes one source to rule them all rather hard. And besides, I don't think Felipe would let any feature suggestion in that adds smartness to bash's completer, that would impact any of his use-cases. That being said, if git would provide a way of saying "The git-am command supports the following flags [...] and the --directory option expects the value type of value: ...", then bash and zsh could both _generate_ completers based on that. Might be neat, but sounds like a bit of work. ;) Okay then. This is far more than I thought I'd ever write on the subject again, but since you asked nicely, you deserved a reasonable answer. Thanks for your patches and good luck with whichever completion you decide to work on! Regards, Frank -- In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away. -- RFC 1925