From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9184 invoked from network); 11 Nov 2003 08:19:56 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 11 Nov 2003 08:19:56 -0000 Received: (qmail 20219 invoked by alias); 11 Nov 2003 08:19:32 -0000 Mailing-List: contact zsh-users-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6756 Received: (qmail 20170 invoked from network); 11 Nov 2003 08:19:31 -0000 Received: from localhost (HELO sunsite.dk) (127.0.0.1) by localhost with SMTP; 11 Nov 2003 08:19:31 -0000 X-MessageWall-Score: 0 (sunsite.dk) Received: from [193.109.254.211] by sunsite.dk (MessageWall 1.0.8) with SMTP; 11 Nov 2003 8:19:31 -0000 X-VirusChecked: Checked X-Env-Sender: okiddle@yahoo.co.uk X-Msg-Ref: server-20.tower-36.messagelabs.com!1068538769!1745270 X-StarScan-Version: 5.1.13; banners=-,-,- Received: (qmail 12627 invoked from network); 11 Nov 2003 08:19:29 -0000 Received: from iris.logica.co.uk (158.234.9.163) by server-20.tower-36.messagelabs.com with SMTP; 11 Nov 2003 08:19:29 -0000 Received: from gmcs3.local ([158.234.142.61]) by iris.logica.co.uk (8.12.3/8.12.3/Debian -4) with ESMTP id hAB8JSAb019578; Tue, 11 Nov 2003 08:19:29 GMT Received: from gmcs3.local (localhost [127.0.0.1]) by gmcs3.local (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id hAB8MvQ09221; Tue, 11 Nov 2003 09:22:57 +0100 X-StarScan-Version: 5.0.7; banners=.,-,- X-VirusChecked: Checked In-reply-to: <20031110182013.GA20547@lorien.emufarm.org> From: Oliver Kiddle References: <20030523160020.GA9026@borho.org> <20030523160155.GA14388@lorien.emufarm.org> <20031106153225.GA491@lorien.emufarm.org> <1281.1068232665@athlon> <20031110182013.GA20547@lorien.emufarm.org> To: Danek Duvall Cc: Jonas Juselius , zsh-users@sunsite.dk Subject: Re: Completion function for bitkeeper? Date: Tue, 11 Nov 2003 09:22:57 +0100 Message-ID: <9219.1068538977@gmcs3.local> Danek Duvall wrote: > 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. Searching for expl in zshcompsys, it is only used in examples. The one exception is in the context of _arguments actions where it isn't just a convention (_arguments can't use positional parameters for actions). I certainly can't see anywhere where it suggests that you can expect it to be set by a calling function. > 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. The two entirely different sets of information system isn't ideal but the positional parameters are the most convenient place for passing information around. The best alternative I can think of would be to have the tag loop function store the compadd options for each level of tag nesting and not use positional parameters for compadd options. Tag loops need rethinking anyway due to problems with label loops being separate. For now completion functions should avoid certain compadd options for passing other information. zparseopts tends to make it easy enough to follow this. If you really want lots of options, follow _arguments and have a `-O array' option for passing compadd options. > 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. compadd arguments aren't passed in $expl. They may coincidentally happen to be lying around in $expl but only because $expl was chosen as a place to have _description store them temporarily before passing them on. Oliver