From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4311 invoked by alias); 26 Apr 2011 21:58:27 -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: 29067 Received: (qmail 22611 invoked from network); 26 Apr 2011 21:58:15 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 Received-SPF: pass (ns1.primenet.com.au: SPF record at benizi.com designates 64.130.10.15 as permitted sender) Date: Tue, 26 Apr 2011 17:52:02 -0400 (EDT) From: "Benjamin R. Haskell" To: Felipe Contreras cc: Mikael Magnusson , Frank Terbeck , zsh-workers@zsh.org, Nikolai Weibull Subject: Re: Slowness issue with git completion In-Reply-To: Message-ID: References: <87liyw7t0o.fsf@ft.bewatermyfriend.org> User-Agent: Alpine 2.01 (LNX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463810530-437985939-1303853036=:28316" Content-ID: ---1463810530-437985939-1303853036=:28316 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Content-ID: On Tue, 26 Apr 2011, Felipe Contreras wrote: > On Tue, Apr 26, 2011 at 11:34 PM, Mikael Magnusson wrote: >> On 26 April 2011 22:23, Felipe Contreras wrote: >>> On Tue, Apr 26, 2011 at 9:43 PM, Frank Terbeck wrote: >>>> Felipe Contreras wrote: >>>>> It's very easy to reproduce: >>>>> % git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git >>>>> linux >>>>> % cd linux >>>>> % git log v >>>>> >>>>> It will take a looong time to figure out anything, specially if >>>>> not cached. I think I recall investigating the issue and finding >>>>> that it's looking for *all* the files in the git repo. >>>> >>>> Well yes. This is a known issue. >>>> >>>> I'm fairly sure that this is due to _multi_parts, which probably >>>> doesn't scale for jobs like that.  I once gave rewriting all that a >>>> shot and ended up with a number of helpers for each "type" of file >>>> etc. (like modified or ignored files).  While they were >>>> significantly quicker than the current code, they were probably >>>> still full of bugs and shortcomings. Also, I would have had to >>>> rewrite *large* parts of the rest of the completion, which would >>>> have been a *major* undertaking. >>>> >>>> In short: It's a known issue and it's very hard to fix (if only >>>> because it is a *lot* of work). >>> >>> Here's a quick solution: don't try to list files. If I want to list >>> files, I would use '-- '. And in fact, that's exactly what the bash >>> completion does. >> >> git accepts files with or without a -- > > So? So if git accepts filenames with or without the '--', Zsh's completion should list filenames with or without the '--'. >>> Moreover, why do you want to be smarter than git? There are ways to >>> ask git precisely what we want: list the contents of certain >>> tree-ish on-demand. And in fact, that's exactly what the bash >>> completion does: >>> >>> time git ls-tree HEAD -- (0m0.005s) >>> time git ls-tree HEAD -- drivers/ (0m0.007s) >> >> git ls-tree doesn't allow you to filter the output files by >> 'changed', 'new', 'unknown' etc etc. > > So? So 'ls-tree' doesn't list context-appropriate completions, which is what Zsh is providing. So, 'ls-tree' can't provide the list of files Zsh needs. The point is that the way bash does it ignores the context cues that Zsh (very-)inefficiently exploits. If you don't care about the correctness, just modify __git_files to only complete anything if it's already seen '--'. Or, far more simply, just disable __git_files entirely. I have +<,> bound to file completion partly so I can complete filenames even in places where it doesn't make sense -- or more often: where Zsh doesn't think it makes sense -- but partly for this workaround in particular. In ~/.zshrc or wherever: " map alt-, to complete files zle -C complete-files complete-word _generic zstyle ':completion:complete-files:*' completer _files bindkey '^[,' complete-files " disable git file completion because it's so slow __git_files(){} It's a workaround. At some point, someone (probably someone participating in this thread) will figure out a proper solution. But until that happens the workaround is better than breaking the context sensitivity of git completion just to make it as fast as bash. -- Best, Ben ---1463810530-437985939-1303853036=:28316--