Re: Slowness issue with git completion

["Benjamin R. Haskell" <zsh@benizi.com>]

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