From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24502 invoked from network); 17 Nov 2003 17:52:21 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 17 Nov 2003 17:52:21 -0000 Received: (qmail 8973 invoked by alias); 17 Nov 2003 17:51:55 -0000 Mailing-List: contact zsh-users-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6783 Received: (qmail 8930 invoked from network); 17 Nov 2003 17:51:54 -0000 Received: from localhost (HELO sunsite.dk) (127.0.0.1) by localhost with SMTP; 17 Nov 2003 17:51:54 -0000 X-MessageWall-Score: 0 (sunsite.dk) Received: from [66.93.131.57] by sunsite.dk (MessageWall 1.0.8) with SMTP; 17 Nov 2003 17:51:53 -0000 Received: from lorien.emufarm.org (localhost [127.0.0.1]) by lorien.emufarm.org (8.12.7/8.12.7) with ESMTP id hAHHpq1C030503; Mon, 17 Nov 2003 09:51:52 -0800 Received: (from duvall@localhost) by lorien.emufarm.org (8.12.7/8.12.7/Submit) id hAHHppLo030502; Mon, 17 Nov 2003 09:51:51 -0800 Date: Mon, 17 Nov 2003 09:51:51 -0800 From: Danek Duvall To: Oliver Kiddle Cc: zsh-users@sunsite.dk Subject: Re: Completion function for bitkeeper? Message-ID: <20031117175151.GA24060@lorien.emufarm.org> Mail-Followup-To: Danek Duvall , Oliver Kiddle , zsh-users@sunsite.dk References: <20031106153225.GA491@lorien.emufarm.org> <1281.1068232665@athlon> <20031110182013.GA20547@lorien.emufarm.org> <9219.1068538977@gmcs3.local> <20031111162338.GD23138@lorien.emufarm.org> <901.1068577572@athlon> <20031111212828.GA28125@lorien.emufarm.org> <29114.1068797096@gmcs3.local> <20031114154608.GA6959@lorien.emufarm.org> <15744.1069084060@gmcs3.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15744.1069084060@gmcs3.local> User-Agent: Mutt/1.5.4i On Mon, Nov 17, 2003 at 04:47:40PM +0100, Oliver Kiddle wrote: > You're not doing something wrong so much as different. People have been telling me this all my life. ;-) > Firstly, the most common case is that there are no options other than > compadd options to get mixed up with so having $expl added is what is > wanted. Fair enough; I certainly understand that. > You wanted the compadd options after your own extra option because it > made it easier to find your option--it would always be the first one. > That made your helper function simpler but puts the onus on the > calling functions to get the options in the right order. Well, not just that it would be easier to find my option, but that my option would be findable at all. As it is, even with zparseopts (which I hadn't known about, so thank you for that), there's no way at all to tell whether a -e that's passed to my helper function is there because I passed it in explicitly through an argument to _arguments, or whether it's part of the set of arguments that's destined only for compadd. There's simply no way for me to know. So then the onus is on me to pick a flag that compadd doesn't already use. It uses seventeen uppercase letters, thirteen lowercase letters, and two numbers, and that's a pretty severe depletion of the usable namespace of flags. But assuming I choose one (and it's even remotely mnemonic), then there's no guarantee that a future release doesn't add a new flag to compadd, and bites me in the ass! So while I understand your explanation, my question of how to do this right is still going unanswered. One answer I can think of is to avoid the use of command-line flags entirely, and just have two different functions. Three probably -- one is the function as it currently is, and two wrapper functions that call the the first either with or without a flag. Then they'd be distinguished by different names. A global shell variable is another answer. But these just seem kludgey to me. > If you found a Unix program which had two independent and unrelated > options -a and -b and the program couldn't cope with them being > specified in the order -b followed by -a, you wouldn't think it was > very good would you? Of course not, but that's not the problem at hand. It's not ordering that's the problem, it's overlapping namespaces. And by the time my function sees the result, the overlap is no longer undoable. It's like merging image layers in GIMP or Photoshop -- you can't reconstruct the layers from the merged result, so you don't know which pixels came from which layer, so you've lost information. Danek