From: Oliver Kiddle <okiddle@yahoo.co.uk>
To: zsh-users@sunsite.dk
Subject: Re: Completion function for bitkeeper?
Date: Tue, 11 Nov 2003 16:21:32 +0100 [thread overview]
Message-ID: <11367.1068564092@gmcs3.local> (raw)
In-Reply-To: <25969.1068547365@csr.com>
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
________________________________________________________________________
next prev parent reply other threads:[~2003-11-11 15:18 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-23 16:00 Steve Borho
2003-05-23 16:01 ` Danek Duvall
2003-11-06 15:32 ` Danek Duvall
2003-11-07 19:17 ` Oliver Kiddle
2003-11-10 18:20 ` Danek Duvall
2003-11-11 8:22 ` Oliver Kiddle
2003-11-11 10:42 ` Peter Stephenson
2003-11-11 15:21 ` Oliver Kiddle [this message]
2003-11-11 15:24 ` Peter Stephenson
2003-11-11 16:13 ` Oliver Kiddle
2003-11-11 16:23 ` Peter Stephenson
2003-11-11 16:44 ` Oliver Kiddle
2003-11-11 16:23 ` Danek Duvall
2003-11-11 19:06 ` Oliver Kiddle
2003-11-11 21:28 ` Danek Duvall
2003-11-14 8:04 ` Oliver Kiddle
2003-11-14 10:47 ` Peter Stephenson
2003-11-14 13:09 ` Oliver Kiddle
2003-11-14 16:12 ` Bart Schaefer
2003-11-14 16:23 ` Peter Stephenson
2003-11-14 17:14 ` Bart Schaefer
2003-11-14 17:01 ` Oliver Kiddle
2003-11-14 15:46 ` Danek Duvall
2003-11-14 21:24 ` Danek Duvall
2003-11-17 15:47 ` Oliver Kiddle
2003-11-17 17:51 ` Danek Duvall
2003-11-19 10:23 ` Oliver Kiddle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=11367.1068564092@gmcs3.local \
--to=okiddle@yahoo.co.uk \
--cc=zsh-users@sunsite.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).