Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Completion function for bitkeeper?
- X-seq: zsh-users 6759
- From: Oliver Kiddle <okiddle@xxxxxxxxxxx>
- To: zsh-users@xxxxxxxxxx
- Subject: Re: Completion function for bitkeeper?
- Date: Tue, 11 Nov 2003 16:21:32 +0100
- In-reply-to: <25969.1068547365@xxxxxxx>
- Mailing-list: contact zsh-users-help@xxxxxxxxxx; run by ezmlm
- References: <25969.1068547365@xxxxxxx>
Peter wrote:
> Oliver Kiddle wrote:
> > 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.
>
> The subtlety of the distinction is a bit lost on me. Isn't that exactly
> the problem Danek is worried about?
I would only share Danek's worry if it was undefined as to where a
function should go looking for compadd options passed to it. It isn't
undefined - compadd options are only explicitly passed to other
completion functions in the positional parameters.
If we take this example:
_foo() {
local expl
_description foo expl foos
_bar "$expl[@]"
}
As a result of zsh having dynamic scoping, _foo's $expl is still
visible inside _bar. _foo happens to use $expl for storing compadd
options to pass on. Knowing this the author of _bar could take
advantage of it but it'd be bad programming (and might break if _bar
was called from elsewhere). To actively prevent it, we need static
scoping.
Does that make sense now?
Oliver
PS. As an aside, needing the expl parameter to _wanted is somewhat
pointless.
________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs Email
Security System. For more information on a proactive email security
service working around the clock, around the globe, visit
http://www.messagelabs.com
________________________________________________________________________
Messages sorted by:
Reverse Date,
Date,
Thread,
Author