From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 715 invoked by alias); 27 Apr 2013 11:43:18 -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: 31344 Received: (qmail 15254 invoked from network); 27 Apr 2013 11:43:15 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE, SPF_HELO_PASS autolearn=ham version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at bewatermyfriend.org does not designate permitted sender hosts) From: Frank Terbeck To: Ramkumar Ramachandra Cc: zsh-workers@zsh.org, Nikolai Weibull Subject: Re: [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer In-Reply-To: (Ramkumar Ramachandra's message of "Sat, 27 Apr 2013 15:52:53 +0530") References: <1366462573-15545-1-git-send-email-artagnon@gmail.com> <1366462573-15545-3-git-send-email-artagnon@gmail.com> <87mwsm3ho5.fsf@ft.bewatermyfriend.org> <87haiu2zwk.fsf@ft.bewatermyfriend.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) Date: Sat, 27 Apr 2013 13:27:34 +0200 Message-ID: <87sj2c1ae1.fsf@ft.bewatermyfriend.org> MIME-Version: 1.0 Content-Type: text/plain X-Df-Sender: [pbs]MDExNTM1 Ramkumar Ramachandra wrote: > Frank Terbeck wrote: [...] >> follows git's development too closely that's a battle you cannot win. [...] > mailing list. Like I said before: I'm not taking sides, so there's no > "battle": it's a simple task of picking one completer, and merging the > other's strengths into it. That's not how I meant "battle". I meant that one person cannot keep up with the rate at which git moves. I didn't mean it in the bash vs zsh completion sense. If the bash completion works well, that's great. [...] >> completion). Long story short, Felipe's rather hostile tone got him a >> pretty short-spoken final reply from Nikolai, which he now shows off to >> anyone who does or doesn't ask. > > Got it. However, why are we talking about him? We're not interested > in changing Felipe's behavior (even if we did have some magical way to > do that). Let us focus on which completer to work on by looking at > the two completers. I merely provided some context, but you've obviously got a point there. ;) >> This whole _git business is rather off-putting and I'd like to avoid >> putting any more time and energy into any "politics" that are involved >> on either side. This is no fun. I don't want to get steamed up about >> things like this. > > Why are you getting steamed up? What politics are you talking about? > Someone on the internet has a rather strong opinion on zsh's > completer, and he tells it to whoever asks him. That's it. Discussing with reasonably mannered people is no problem at all. People on the other hand, who are abusive and insulting for no particular reason other than the effect it has on the people on the other side of the "discussion" can be infuriating - which is obviously what they are aiming for, but what can you do. ;) I'd really like to follow your suggestion and drop this matter now. >> This thing with speed is this: Yes, _git is slower than the bash >> completion. But - at least when I last looked - _git will provide much >> more useful suggestions depending on the context of the cursor position. >> And I - personally - am happy to wait for, say, a second if that means I >> can save several seconds selecting the right choice. However, some >> completions are too slow on really large repositories. That would be a >> useful area to improve - maybe make the slow smartness optional? I don't >> know. > > The question is: which way to start work from? [...] I don't know. It seems that the two completers have different philosophies in the ways they work, so merging them seems like a long-running and tedious job. Like I said before, having a source that describes possible completions would be a step in the right direction. Also, non-bourne-like shells like tcsh and fish could benefit from that. Regards, Frank -- In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away. -- RFC 1925