Zsh Mailing List Archive
Messages sorted by:
Re: Completion function for bitkeeper?
- X-seq: zsh-users 6756
- From: Oliver Kiddle <okiddle@xxxxxxxxxxx>
- To: Danek Duvall <duvall@xxxxxxxxxxx>
- Subject: Re: Completion function for bitkeeper?
- Date: Tue, 11 Nov 2003 09:22:57 +0100
- Cc: Jonas Juselius <jonas@xxxxxx>, zsh-users@xxxxxxxxxx
- In-reply-to: <20031110182013.GA20547@xxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-users-help@xxxxxxxxxx; run by ezmlm
- References: <20030523160020.GA9026@xxxxxxxxx> <20030523160155.GA14388@xxxxxxxxxxxxxxxxxx> <20031106153225.GA491@xxxxxxxxxxxxxxxxxx> <1281.1068232665@athlon> <20031110182013.GA20547@xxxxxxxxxxxxxxxxxx>
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
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
Messages sorted by: