From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16113 invoked from network); 8 Aug 2004 16:48:16 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 8 Aug 2004 16:48:16 -0000 Received: (qmail 42702 invoked from network); 8 Aug 2004 16:48:10 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 8 Aug 2004 16:48:10 -0000 Received: (qmail 14719 invoked by alias); 8 Aug 2004 16:47:58 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 20243 Received: (qmail 14709 invoked from network); 8 Aug 2004 16:47:57 -0000 Received: from unknown (HELO a.mx.sunsite.dk) (130.225.247.88) by 130.225.247.90 with SMTP; 8 Aug 2004 16:47:57 -0000 Received: (qmail 42027 invoked from network); 8 Aug 2004 16:46:25 -0000 Received: from unknown (HELO moonbase.zanshin.com) (167.160.213.139) by a.mx.sunsite.dk with SMTP; 8 Aug 2004 16:46:23 -0000 Received: from toltec.zanshin.com (toltec.zanshin.com [64.84.47.166]) by moonbase.zanshin.com (8.12.11/8.12.11) with ESMTP id i78GkMgs012907 for ; Sun, 8 Aug 2004 09:46:22 -0700 Date: Sun, 8 Aug 2004 09:46:22 -0700 (PDT) From: Bart Schaefer Reply-To: zsh-workers@sunsite.dk To: Zsh Subject: Re: default tag-order (was Re: zsh 4.2.1-test-A) In-Reply-To: Message-ID: References: <200408061350.i76DovBi028948@news01.csr.com> <20040806180339.GA31854@scowler.net> <10094.1091886003@trentino.logica.co.uk> <20040808044557.GA8117@scowler.net> <16609.1091976020@trentino.logica.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 on a.mx.sunsite.dk X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=6.0 tests=BAYES_00 autolearn=no version=2.63 X-Spam-Hits: -4.9 On Sun, 8 Aug 2004, Bart Schaefer wrote: > On Sun, 8 Aug 2004, Oliver Kiddle wrote: > > > The problem is with the default tag-order defined in _tags. The relevant > > bit of code is as follows: > > zstyle -a ":completion:${curcontext}:" tag-order order || > > order=('(|*-)argument-* (|*-)option[-+]* values' options) > > > > One safe option is to insert `(( ! ${@[(I)options]} )) ||'. > > That checks if there is an options tag before applying the tag-order. > > I'm confused by this suggestion. If there's no options tag, the tag-order > doesn't make any difference, because it's in the second group of tags. > And in the case of cdrecord, there _is_ an options tag. OK, I worked this out now. The problem is that there's no options tag *in the argument-rest subcontext* but there are both values and files tags, so the presence of values in this tag hides the files. Sorry to be dense. The canonical examples of _values are _dd and _chmod, neither of which allows ambiguity in whether an argument is a value or a filename (dd takes only values, and chmod requires exactly one value before any filename). So I suspect this simply never came up before.