From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23210 invoked from network); 11 Nov 2003 21:29:04 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 11 Nov 2003 21:29:04 -0000 Received: (qmail 14677 invoked by alias); 11 Nov 2003 21:28:43 -0000 Mailing-List: contact zsh-users-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6766 Received: (qmail 14624 invoked from network); 11 Nov 2003 21:28:42 -0000 Received: from localhost (HELO sunsite.dk) (127.0.0.1) by localhost with SMTP; 11 Nov 2003 21:28:42 -0000 X-MessageWall-Score: 0 (sunsite.dk) Received: from [66.93.131.57] by sunsite.dk (MessageWall 1.0.8) with SMTP; 11 Nov 2003 21:28:42 -0000 Received: from lorien.emufarm.org (localhost [127.0.0.1]) by lorien.emufarm.org (8.12.7/8.12.7) with ESMTP id hABLST1C029548; Tue, 11 Nov 2003 13:28:29 -0800 Received: (from duvall@localhost) by lorien.emufarm.org (8.12.7/8.12.7/Submit) id hABLSS0v029547; Tue, 11 Nov 2003 13:28:28 -0800 Date: Tue, 11 Nov 2003 13:28:28 -0800 From: Danek Duvall To: Oliver Kiddle Cc: Jonas Juselius , zsh-users@sunsite.dk Subject: Re: Completion function for bitkeeper? Message-ID: <20031111212828.GA28125@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> <20031110182013.GA20547@lorien.emufarm.org> <9219.1068538977@gmcs3.local> <20031111162338.GD23138@lorien.emufarm.org> <901.1068577572@athlon> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <901.1068577572@athlon> User-Agent: Mutt/1.5.4i On Tue, Nov 11, 2003 at 08:06:12PM +0100, Oliver Kiddle wrote: > Sorry, I should have been more clear. What I mean is actually in the > _arguments action itself not within a function called as part of the > action. Looking at the documentation, it isn't as clear on this as it > should be. It doesn't help that in the rearrangement of the > documentation, the expl mention has become separated from the > `{eval-string}' action form and a little from the initial space > feature (have a look at 4.0 documentation). > > Basically, it is intended so you can do things like this: > > '-a:desc: _foo -x -y -z "$expl[@]" a b c' > '-b:desc:{compadd "$expl[@]" one two three}' Okay, I see what you mean now. It's not intended for $expl here to be visible inside the function that's called, but it is, because of the scoping issues you and Peter are talking about. Is there any reason (other than it would break code relying on the current behavior) not to just require someone to explicitly add $expl to the action, so that they can control where it goes? You can do that now by prefixing with a space, but ... that just seems a bit silly to me ... too much automation for a case that doesn't really require it. But now that I understand it, I guess I can live with it. > Any ideas on how to make the documentation clearer on this? I'm not sure. I think what made it click for me was your example above. Perhaps saying that '-a:desc:_foo -x -y -z a b c' is equivalent to '-a:desc: _foo "$expl[@]" -x -y -z a b c' as a "that is" statement somewhere in that paragraph would be helpful? Getting rid of the automatic passing would certainly help make the documentation easier to write here. The root of the problem is that I was getting arguments in my function called from the action that I didn't know how to deal with, and I didn't know how to ignore, other than putting the initial space in, which felt like a kludge, or possibly the wrong answer. If that's the only confusion that needs to be addressed, perhaps we could say that if a function called as an action wants to do argument parsing, it may have difficulty because of the options passed to it by _arguments. Such a function should probably be called in an action starting with a space to avoid the problem, and $expl[@] be passed explicitly in such a way that the function can handle extracting those arguments from the non-compadd related ones. Then, if you really wanted to lay it on thick, you could also mention that trying to extract the contents of $expl as _arguments sees it from within the function is not supported, and that it only works because there's currently no way to prevent the function from inheriting it from _arguments, but that may change at some point in the future. > How's that bitkeeper function doing these days by the way? Is it at a > stage we could include with zsh? Does it conflict with _sccs? Well, none of the usual zsh folks commented on it, so while it works for me, I don't feel it's undergone much review. There's some work that still needs to be done, I think: - flesh out all the bk sub-commands; not all of them have clauses in _bk yet - there are a number of comments in the function that indicate things I couldn't quite figure out what to do - I don't think that it conflicts with _sccs at all, but it might be nice to get _sccs to use _sccsfiles in the appropriate places. - _sccsfiles probably should have some way of controlling the depth to which it searches for matches. Currently, it just does **/ and if that has to search through tens of thousands of files and directories, then you're just going to have to wait, and I don't think that's necessarily the best behavior. Suggestions for more appropriate behavior would be greatly appreciated. Other than that, I'm perfectly happy for any of this stuff to get into the tree. Thanks, Danek