From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14643 invoked from network); 10 Nov 2003 18:20:42 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 10 Nov 2003 18:20:42 -0000 Received: (qmail 26668 invoked by alias); 10 Nov 2003 18:20:25 -0000 Mailing-List: contact zsh-users-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6755 Received: (qmail 26594 invoked from network); 10 Nov 2003 18:20:24 -0000 Received: from localhost (HELO sunsite.dk) (127.0.0.1) by localhost with SMTP; 10 Nov 2003 18:20:24 -0000 X-MessageWall-Score: 0 (sunsite.dk) Received: from [66.93.131.57] by sunsite.dk (MessageWall 1.0.8) with SMTP; 10 Nov 2003 18:20:24 -0000 Received: from lorien.emufarm.org (localhost [127.0.0.1]) by lorien.emufarm.org (8.12.7/8.12.7) with ESMTP id hAAIKE1C021150; Mon, 10 Nov 2003 10:20:14 -0800 Received: (from duvall@localhost) by lorien.emufarm.org (8.12.7/8.12.7/Submit) id hAAIKDuR021149; Mon, 10 Nov 2003 10:20:13 -0800 Date: Mon, 10 Nov 2003 10:20:13 -0800 From: Danek Duvall To: Oliver Kiddle Cc: Jonas Juselius , zsh-users@sunsite.dk Subject: Re: Completion function for bitkeeper? Message-ID: <20031110182013.GA20547@lorien.emufarm.org> Mail-Followup-To: Danek Duvall , Oliver Kiddle , Jonas Juselius , zsh-users@sunsite.dk References: <20030523160020.GA9026@borho.org> <20030523160155.GA14388@lorien.emufarm.org> <20031106153225.GA491@lorien.emufarm.org> <1281.1068232665@athlon> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1281.1068232665@athlon> User-Agent: Mutt/1.5.4i On Fri, Nov 07, 2003 at 08:17:45PM +0100, Oliver Kiddle wrote: > Looking inside expl is not a good idea as the array name expl is > purely a convention. I agree that if it's merely a convention that I shouldn't use it. However, the zshcompsys man page explicitly documents it, suggesting that it's safe to use. If it's not, perhaps removing it from the documentation is the right thing to do. > Try using zparseopts to find and remove that -e option instead: > zparseopts -D -E e=eopt > [[ -n $eopt ]] && sfile="SCCS/p." That works, thanks. Still, this whole thing feels like a fragile interface. Two entirely different sets of information are being passed to the function on the commandline, which at the very least means that there's a potential for flag collision (what happens if _arguments decides to pass in -e for compadd purposes?), never mind the parsing difficulties. It seems that using some other method for passing in compadd arguments would be better ... such as using a well-known parameter name. :) I still maintain that passing in the compadd arguments both on the commandline and in $expl is a bug, as it's duplicative, redundant, repetitive, and redundant. Danek