On Wed, 27 Apr 2011, Felipe Contreras wrote:

> On Wed, Apr 27, 2011 at 1:03 AM, Nikolai Weibull wrote:
>> On Tue, Apr 26, 2011 at 23:35, Felipe Contreras wrote:
>>> On Wed, Apr 27, 2011 at 12:13 AM, Mikael Magnusson wrote:
>>
>>>> It's only slow in repos as large as the linux one.
>>
>>> No. It's slow everywhere, it's *dead* slow on Linux. And BTW, 
>>> there's thousands of developers working on Linux (the kernel), I 
>>> guess we are not important.
>>
>> So perhaps you can improve it then.  Or one of the thousands of 
>> developers working on Linux (the kernel).  (I don’t believe that a 
>> very large fraction of them actually use Zsh,
>
> And now I see why.
>
>> though, or someone would have already provided a patch.)  Or perhaps 
>> you could patch the kernel to make it faster?
>
> It works fine in bash.
>
>> I’ve spent innumerable hours on making it correct.  I expect someone 
>> to pitch in a couple of hours to make it fast.
>
> Well, kernel and git developers have spent many more hours to make git 
> fast,  and this "correctness" is disrespecting that work because the 
> time it takes to execute the completion is longer than the command 
> itself.

Developing a slow solution around something highly optimized isn't 
"disrespecting" anything.  It's not taking advantage of that 
optimization, but that's hardly an act of "disrespect".


>> I find your attitude in this thread rather offensive.
>
> Oh, if I say the current implementation is dead slow and unusable, you
> find that offensive?

He presumably finds the snarky and/or holier-than-thou comments offensive:

"And now I see why"

"It works fine in bash"

"there's thousands of developers working on Linux (the kernel), I guess we are not important"

"Seriously, this is very annoying" [from your earlier message]

multiple dismissive "So?" responses [also in earlier messages]


> Maybe you should understand that criticism to code is not criticism to 
> you. But I will tell you what I do when somebody finds a fatal flaw in 
> my software; I fix it. If the person is offensive or cordial doesn't 
> really matter, the fatal flaw is there.

Many people do not consider cordiality to be an optional component of a 
request for volunteer effort.  The kernel community has a very different 
level of expected tact, apparently and expectedly.


> Now, how about you make a compromise between "correctness" and 
> usability? There's many parts of the code marked as TODO, so I guess 
> the code is not "perfectly correct". Add one more TODO, so in the 
> meantime 'git add' shows unchanged files, which would make the rest of 
> the commands as fast as they should be.

[see my other response -- gist: if it weren't broken the "context 
sensitivity" would be preferred, so the effort to rip it out perhaps isn't 
deemed to be worthwhile]


> I will tell you why I use completion; because I want to be more 
> productive. If completion makes me less productive, I will obviously 
> not use it... What's the point? I don't see why that is so hard to 
> understand. Note that this is the case also for small projects.
>
> 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.  People who understand 
completion better than I do can continue on whichever path they prefer 
(whether the choice is "Worse is Better" vs "the Right Thing" OR 
cathedral vs bazaar is left as an exercise to the reader).

-- 
Best,
Ben