From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 364 invoked by alias); 5 May 2011 23:01:38 -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: 29160 Received: (qmail 2807 invoked from network); 5 May 2011 23:01:26 -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=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 Received-SPF: pass (ns1.primenet.com.au: SPF record at _spf.google.com designates 209.85.161.43 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FFNFtTwaL7q5RvbLYhSdwgY6VddZoMpOeotSmED7bIU=; b=bBlMnxJBIGOhgjSywt7fCV1AJxtVu7fjfoBXtvuzwWJvkXONgasJyBHR8PGDhaSK7W TOXWEbr/t0kkESpCVti0bPMn1lX6yOIV3Jr/xS31g542XBiEGf3BLA/525ninKpU2NBo KpfMwiJjRwFz3WrD2FUv8neTnEOCPP6YQXKWE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=c/Ja9EWTpWNE2r0Xwc4+AsIQrI/4uEV7CgVTIvBldZv2NkBZNpNmrIeJuYKCTL5eYW 7/iA5w42javXUjhTEL17N0V93RLhPVA/aVXyFS1Tb1hLWBP6lL6r3+3bp+tsB6AbULnC Pk/ADfMBkYSVMn3yNXQ4O6dYDR84gtHK+neDs= MIME-Version: 1.0 In-Reply-To: <110505153721.ZM20011@torch.brasslantern.com> References: <110505153721.ZM20011@torch.brasslantern.com> Date: Fri, 6 May 2011 02:01:20 +0300 Message-ID: Subject: Re: When can we make a compromise in Git completion? From: Felipe Contreras To: Bart Schaefer Cc: zsh-workers@zsh.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, May 6, 2011 at 1:37 AM, Bart Schaefer w= rote: > On May 6, =C2=A01:07am, Felipe Contreras wrote: > } Subject: When can we make a compromise in Git completion? > } > } Actually I saw that mail by looking at the archives, but I didn't > } notice the patch. I have tried the patch, it's still *dead slow* for > } me. Again, I don't think this can be solved without writing new git > } plumbing. You need to avoid 'git ls-files'. > > With the patch, however, it's possible for you to plug in your own > different plumbing using zstyle. > > zstyle ':completion::complete:git:*:files' command ... > > where you put your alternate plumbing in where I have "...". I don't think it would be that easy. > Then when you have something that works as fast/accurately as you care > about, you can let us know. > > If that's not good enough you can rewrite __git_files (or any of the > other functions in the _git file) from scratch; there's a reason that > the source file tests (( $+functions[__git_files] )) || ... before > each function is defined: =C2=A0so that you can override them simply by > defining your own flavor before _git is autoloaded. I believe every __git_.*_files has to be changed. So again, not that easy. Why would I even try if the result of this work is going to the trash? First you tell me you would consider it for merging, then I will try it, no point otherwise. > } So. At which point are you going to be willing to accept the fact that > } it's not possible to fix the performance without making a compromise? > > Roughly at the time you stop taking such an antagonistic stance about > it, I suspect. =C2=A0Really, you're not doing your efforts any favors by > framing the discussion the way you do. This has nothing to do with feelings, it's a technical issue. Either you are willing to make a compromise or not. You pointed to other mailing list customs earlier, well, on the linux kernel mailing list politeness is not a requisite, code is: "talk is cheap, show me the code". But what I hear you saying is; "we don't want that code". It is a simple question, why can't you give a straight answer? --=20 Felipe Contreras