From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: zsh-workers-return-43531-ml=inbox.vuxu.org@zsh.org X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id d59b3b28 for ; Mon, 24 Sep 2018 18:00:31 +0000 (UTC) Received: (qmail 19368 invoked by alias); 24 Sep 2018 18:00: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: List-Unsubscribe: X-Seq: 43531 Received: (qmail 6887 invoked by uid 1010); 24 Sep 2018 18:00:18 -0000 X-Qmail-Scanner-Diagnostics: from out1-smtp.messagingengine.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(66.111.4.25):SA:0(-1.1/5.0):. Processed in 6.190926 secs); 24 Sep 2018 18:00:18 -0000 X-Envelope-From: d.s@daniel.shahaf.name X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= daniel.shahaf.name; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=h6eB/f VQHW9IZid2u8mD/agDFNj4akUDvoGWozuatxM=; b=Q8H/k4yKHFaaKkNbk1gUy3 8XYvMz5S1a8F6UjOcrvVRS73v8+XS/98IKyM0QdirvWmcrMhecN1nZn72wA6dCgR svd3V2qdGAcVE+GUCVmSdApxGQzKpLrwE50TGLP3n7UXAVRCM4zXmCNK9ce0CNOc 9T0NB2Gk1LtkxbOVI7468UmR2wJSbMG/urfi64nRlzZLni5A3sp2G+17dS9sBDzp j7NRHRAEaVTdQ7/MANsQ3mJztBMUvN3yrDhUTVg8XFncMqqv79PITWokutpQ4nLl UDRXO9AcLZ21jRWDSckVbefRP4eJgqlB8+eoQMpHrGs9YZK6qkuChDeQguWAP9qQ == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=h6eB/f VQHW9IZid2u8mD/agDFNj4akUDvoGWozuatxM=; b=Z1D+0vaUzZ6FL2cHOcnCVq pjJIOJ06RY4H/kVrR2wTytcbuiRrN3bM2YKbutDxqMpWImprieGKmSLfi+Tsbs83 Rm1Q6nRxU+8EnBcdSc8gsiFgpXGFKkz7blB2ZMClCmxXu3VrjtyOQrqa/Th6YH4Y QT5yjFTaggSv52NmQDgLB14M2hGUWZ9etT5AnY0IrNDyNY2Oo8OoqFuow392WP9L Wwhpr+h7D+FM/2hUM3Iz0cQylp06jlD19yu5yPYGaeSOfG8H4td08Uu1V2763fVS GLiDVXwUOMXMkWskvXVMiHW45fhpVGXk6civzwv3cmSE1VVkeuLmiFvYWUg7M3zw == X-ME-Proxy: X-ME-Sender: Date: Mon, 24 Sep 2018 18:00:00 +0000 From: Daniel Shahaf To: Marc =?iso-8859-1?Q?Cornell=E0?= , zsh-workers@zsh.org Subject: Re: [BUG] git checkout completion shows duplicated branch names Message-ID: <20180924180000.m257nywzw3os6fwh@tarpaulin.shahaf.local2> References: <1537805063.1343776.1518857576.402E4300@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1537805063.1343776.1518857576.402E4300@webmail.messagingengine.com> User-Agent: NeoMutt/20170113 (1.7.2) Daniel Shahaf wrote on Mon, Sep 24, 2018 at 16:04:23 +0000: > Marc Cornellà wrote on Mon, 24 Sep 2018 14:51 +0000: > > Furthermore, on versions prior to commit 4dddf3aa (< zsh-5.6), the > > completion is even worse since a branch > > is not fully completed even if there isn't any other branch with the > > same prefix. > > > > So typing this: > > > > ~/repo% git checkout topic/ > > topic/foo -- Initial commit > > topic/foo > > > > gets completed to `git checkout topic` instead of the full branch name. > > > > With 'zsh -f' + 'autoload compinit; compinit', «git checkout t» > gives me «git checkout topic/foo» and a subsequent > displays possible completions. That is better than the behaviour you > get, but I agree it shouldn't be treating this situation as an ambiguous > completion. I don't know offhand where the relevant piece of code is, > though. Probably in the internals of bin_compdescribe/bin_compadd? > > Here's a minimal example: > > _f() { > local a=( foo:FOO bar:BAR ) expl > _describe -t lorem "lorem" a > _wanted ipsum expl 'ipsum' compadd foo bar > } > compdef _f f > f f This seems to fix it: [[[ diff --git a/Src/Zle/compcore.c b/Src/Zle/compcore.c index 8eca39447..6118c62c1 100644 --- a/Src/Zle/compcore.c +++ b/Src/Zle/compcore.c @@ -3160,9 +3160,7 @@ matcheq(Cmatch a, Cmatch b) matchstreq(a->ppre, b->ppre) && matchstreq(a->psuf, b->psuf) && matchstreq(a->suf, b->suf) && - ((!a->disp && !b->disp && matchstreq(a->str, b->str)) || - (a->disp && b->disp && !strcmp(a->disp, b->disp) && - matchstreq(a->str, b->str))); + matchstreq(a->str, b->str); } /* Make an array from a linked list. The second argument says whether * ]]] Can anyone think of a reason to consider matches different if their display strings both exist, and differ; or if one of them has a display string and one does not? Marc, thanks for asking — this has been annoying me, too. ☺ Cheers, Daniel