From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27853 invoked by alias); 27 Apr 2011 07:01:56 -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: 29079 Received: (qmail 3356 invoked from network); 27 Apr 2011 07:01:42 -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: Wed, 27 Apr 2011 03:01:13 -0400 (EDT) From: "Benjamin R. Haskell" To: Felipe Contreras cc: Nikolai Weibull , Mikael Magnusson , Frank Terbeck , zsh-workers@zsh.org 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: TEXT/PLAIN; charset=US-ASCII; format=flowed On Tue, 26 Apr 2011, Benjamin R. Haskell wrote: > On Wed, 27 Apr 2011, Felipe Contreras wrote: >> Now, how about you make a compromise between "correctness" and >> usability? [...] Are you interested in fixing this use-case even if >> it means to make some compromises in correctness or not? > > I'll take a look at a better workaround tonight. [...] Aside from the segfault that I just reported, the following seems to be a far better out-of-tree workaround (i.e. in ~/.zshrc or thereabouts). Completion returns in less than a second in the kernel repo, grabbing correct-looking files and directories. But the segfault seems to occur when successfully completing a file in any dir other than the root, rendering this useless for the moment. __git_files () { # localize options as appropriate local compadd_opts opts tag description # ignore compadd-related options that __git_files passes along zparseopts -D -E -a compadd_opts V: J: 1 2 n f X: M: P: S: r: R: q F: # ignore git ls-files options that __git_files uses zparseopts -D -E -a opts -- -cached -deleted -modified -others -ignored -unmerged -killed x+: --exclude+: # __git_files expects a tag and a description tag=$1 description=$2 ; shift 2 # but we ignore those and call __git_tree_files against the HEAD revision # with the current PREFIX __git_tree_files ${PREFIX:-.} HEAD } If moved in-tree, this function could be renamed to __git_files_shortcircuit, and the real __git_files could be modified to use this function except when $curcontext =~ *:git-add: (perhaps conditioned on some zstyle). I tend to favor "correctness" over shortcuts like this[1]. But, I'm also of the opinion that "virtually-instantaneous, kindof-correct" is better than "virtually-forever, absolutely-correct"[2]. Will take a look at the segfault again tomorrow if no one sees something obvious. -- Best, Ben [1] http://www.zsh.org/mla/workers/2010/msg00297.html [2] http://lists.pioto.org/pipermail/paludis-user/2008-December/000726.html