From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11081 invoked from network); 8 Aug 2004 16:05:27 -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:05:27 -0000 Received: (qmail 24042 invoked from network); 8 Aug 2004 16:05:21 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 8 Aug 2004 16:05:21 -0000 Received: (qmail 8886 invoked by alias); 8 Aug 2004 16:05:11 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 20241 Received: (qmail 8870 invoked from network); 8 Aug 2004 16:05:10 -0000 Received: from unknown (HELO a.mx.sunsite.dk) (130.225.247.88) by 130.225.247.90 with SMTP; 8 Aug 2004 16:05:10 -0000 Received: (qmail 23068 invoked from network); 8 Aug 2004 16:03:12 -0000 Received: from unknown (HELO moonbase.zanshin.com) (167.160.213.139) by a.mx.sunsite.dk with SMTP; 8 Aug 2004 16:03:10 -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 i78G37FU003805; Sun, 8 Aug 2004 09:03:07 -0700 Date: Sun, 8 Aug 2004 09:03:07 -0700 (PDT) From: Bart Schaefer Reply-To: zsh-workers@sunsite.dk To: Zsh cc: 258431@bugs.debian.org Subject: Re: default tag-order (was Re: zsh 4.2.1-test-A) In-Reply-To: <16609.1091976020@trentino.logica.co.uk> 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, 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) > > There are a few different things we could do here. I can't work out why > "values" needs to be in there. > > 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. How would that proposed change help? > Any other thoughts? > > Default tag-orders really need thinking about in general. It'd be nice > to be able to specify them from completion functions themself. Why is that not possible? For example, several completion functions set the cache-policy style if it's not already set.