From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11531 invoked by alias); 7 Oct 2015 19:06:29 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 20704 Received: (qmail 23731 invoked from network); 7 Oct 2015 19:06:26 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version:content-type; bh=3WJQdw6Imc1oYjPa7AiNMrbc4G2TOosajec/7uwWbUQ=; b=AkD2okcmn/nmC7m83psRcER4d/BrQ6DMVAJrwZdPpWzVaFf2rkL1ec6H9uSvL7lLxw jEVZ+5/hWH0wf3/NJxksfNj3spY/qIVVmm3VwWFQSsNp+fY+o/5hC5VhWfvf3YsUcDyj yUsc/ZlfzjhusjHnYrvkP/aP3ehUz56Tp1oiZ/HbKy2adbyqIvkcQTfs/hyeC0cKOqrL EkO2jYiInB3p9RWkFPPPsiW69YKatRXZbAB/XqjAgUqzdHrK8IY5sHJE5UKNed34MiSH nPBlISLcleHLWuHMs3Nm7Z2/BOhFzL+QU0MlrD7Bnm6CXm2WO/vlXyIVNY7Qp4PBs5EE u08A== X-Gm-Message-State: ALoCoQm7rAArnfRTubWfAqBG9MKsfzQ7kKtgatMxFUzaRQSL/+xr2aXJ3cVSwVcDzMlwgK+8xRUz X-Received: by 10.60.160.37 with SMTP id xh5mr1945447oeb.61.1444244784008; Wed, 07 Oct 2015 12:06:24 -0700 (PDT) From: Bart Schaefer Message-Id: <151007120616.ZM2740@torch.brasslantern.com> Date: Wed, 7 Oct 2015 12:06:16 -0700 In-Reply-To: <20151007142421.2ebb2287@pwslap01u.europe.root.pri> Comments: In reply to Peter Stephenson "Re: tag-order with git refs" (Oct 7, 2:24pm) References: <20151007120820.6f8a59e9@pwslap01u.europe.root.pri> <20151007142421.2ebb2287@pwslap01u.europe.root.pri> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: "Zsh Users' List" Subject: Re: tag-order with git refs MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Oct 7, 2:24pm, Peter Stephenson wrote: } } I mean what tag-order is supposed to be for, preferring matches for } earlier tags if there are any ("shown" isn't the right word except in } so much as they are shown if you're listing). If there are matches for } local heads, I want to see only these, so it doesn't go round the tag } loop to find other matches. That's supposed to be fairly } straightforward to do. I think this comes down to the way __git_heads_local calls _wanted. I compared with a completion where tag-order works and one difference is that there's nothing in a group named "heads-local" at the time comptags is called. Different sets of options are given different descriptions, so they get broken out in the listing, but they're all put in the -default- group as far as I can tell. Maybe this is a bug downstream of _wanted, but instead of _wanted heads-local ... one has to call _wanted heads-local:DESCRIPTION:ACTION ... in order to cause _all_labels to pass a -J option to compadd and thereby make tag-order work. Or at least I think that's what's going on, I'll probably shortly be proved wrong.