Re: Slowness issue with git completion

[Felipe Contreras <felipe.contreras@xxxxxxxxx>]

On Wed, Apr 27, 2011 at 11:47 AM, Frank Terbeck <ft@xxxxxxxxxxxxxxxxxxx> wrote:
> Felipe Contreras wrote:
>> On Wed, Apr 27, 2011 at 9:11 AM, Nikolai Weibull <now@xxxxxxxx> wrote:
>>>> Are you interested in fixing this use-case even if it means to make
>>>> some compromises in correctness or not?
>>>
>>> No, I’m not.
>>
>> I am not used to zsh development, so is Nikolai's opinion shared by
>> the rest? Even if I provide a fix that make things slightly less
>> correct but usable, you wouldn't take the patch?
>
> I for one, am very fond of the way completion is done (albeit, not its
> performance in huge repositories).  It actually *saves* me a whole lot
> of time, because - for example - "git add" only completes file names
> that actually *need* to be staged.  So I would be firmly against
> throwing out Nikolai's hard work.
>
> As I was saying in another mail¹, I was also thinking about a scheme to
> give the user the option to choose smart (and slow) and utterly-dumb
> (and quick) file completion in various contexts via zstyle.  A boolean
> style is very quick to look up and wouldn't impact performance. That
> way, each user could have it his/her way, fine tuned for all git
> sub-commands. That would be something everyone should be able to live
> with.
>
> Also, improving performance of the existing code would be highly
> appreciated.

I believe the only way to achieve good performance is to write new
helper commands in git.git. I could do that, but first I want the
completion to be fast _now_, and only when the "correct" completion
performs in a reasonable way, then enable it.

Since I'm not seeing a huge amount of reasonable responses (usability
is not important), I'm thinking there's really no point in trying to
improve the zsh completion and I should use the bash one instead.

-- 
Felipe Contreras