From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29668 invoked by alias); 7 Oct 2015 13:24:50 -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: 20703 Received: (qmail 26042 invoked from network); 7 Oct 2015 13:24:47 -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-AuditID: cbfec7f5-f794b6d000001495-3e-56151d1b6b46 Date: Wed, 07 Oct 2015 14:24:21 +0100 From: Peter Stephenson To: Zsh Users' List Subject: Re: tag-order with git refs Message-id: <20151007142421.2ebb2287@pwslap01u.europe.root.pri> In-reply-to: References: <20151007120820.6f8a59e9@pwslap01u.europe.root.pri> Organization: Samsung Cambridge Solution Centre X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsVy+t/xq7rSsqJhBvtPGlrsOLmS0YHRY9XB D0wBjFFcNimpOZllqUX6dglcGTe2Gxe85anYtLiXsYFxFVcXIweHhICJxI0dBl2MnECmmMSF e+vZuhi5OIQEljJKvOqfxA7hTGOSeLvnFROEs5VRYsa9rywgLSwCqhIT9xxiBbHZBAwlpm6a zQhiiwioS6y43s4EYgsLqEicef+VHcTmFbCX2LJpFxvIZk6BYInGN94QM9uAtnVcBJvJL6Av cfXvJyaIk+wlZl45wwjRKyjxY/I9sBpmAS2JzduaWCFseYnNa94yg9hCQHtv3N3NPoFRaBaS lllIWmYhaVnAyLyKUTS1NLmgOCk910ivODG3uDQvXS85P3cTIyRkv+5gXHrM6hCjAAejEg/v D2ORMCHWxLLiytxDjBIczEoivI3fgUK8KYmVValF+fFFpTmpxYcYpTlYlMR5Z+56HyIkkJ5Y kpqdmlqQWgSTZeLglGpgTNu6rJ0h8pP43yxBtTXzW9+9F/ZQnxrWXiwtG7pT6c/vt78m2pV6 82ic2Lv+bfRmfg3nx+rv9ZS+hM7dldLjIN6nExW81unehZBDXxyzD4QrRTucn7j3K3flrC3r XeuWnjHkPPgjqXxK6KEp4l9addtqP/jGvlln4MS1Iyh7xYWC6pAqs3JfJZbijERDLeai4kQA BGZtuFUCAAA= On Wed, 7 Oct 2015 15:01:27 +0200 Mikael Magnusson wrote: > I get the same result as you; this has no effect. However, > zstyle ':completion:*:complete:git-checkout:*' group-order heads-local > does work. The question is a bit unclear, you can't limit something to > being shown first 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. There must be *something* special about the git competion that's preventing it, though probably obscure and quite likely a side effect of some completion "feature". I can see this working with Perforce: zstyle ':completion:*:p4-*:at-suffix:*' tag-order changes '*' correctly limits completion after p4 files Makefile@ to just changes applicable to Makefile and not, for example, labels --- labels and changes mean something for present purposes pretty much like tags and commits (don't write in if you're a Perforce expert :-)). That's the general effect I'm after. > but at least with group-order, if you don't mind > getting spammed with other results That's what I'm trying to avoid. There are way too many other results to make the listing remotely useful unless I limit it. I'd like to focus on getting that to work. I already have grouping under headings which is enough for visibility for the matches I do want. pws