Re: Completion function for bitkeeper?

[Oliver Kiddle <okiddle@yahoo.co.uk>]

Danek Duvall wrote:

> As it is, even with zparseopts (which I hadn't known about, so thank you
> for that), there's no way at all to tell whether a -e that's passed to
> my helper function is there because I passed it in explicitly through an
> argument to _arguments, or whether it's part of the set of arguments
> that's destined only for compadd.  There's simply no way for me to know.

-e will only ever be there if you passed it explicitly. Though -e is an
option to compadd, it really wouldn't make sense to pass it to a
completion function. So you're safe with -e. Admittedly you would
not be safe had you chosen -x.

> So then the onus is on me to pick a flag that compadd doesn't already
> use.  It uses seventeen uppercase letters, thirteen lowercase letters,
> and two numbers, and that's a pretty severe depletion of the usable
> namespace of flags.  But assuming I choose one (and it's even remotely

A good few are safe to use: -a, -k, -f, -e, -W and -U are all safe. I'm
not sure about some such as -l, -Q, -C and -E without looking in more
detail. That perhaps should be documented somewhere.

> mnemonic), then there's no guarantee that a future release doesn't add a
> new flag to compadd, and bites me in the ass!

No there isn't but no compadd options have been added in a long while.
We can do a search on distributed functions if we do ever add one.

> So while I understand your explanation, my question of how to do this
> right is still going unanswered.

I think I've now explained how best to do this given the constraints of
the completion system as it currently stands.

I agree that it isn't ideal. The best alternative I can think of would
be to pass compadd options to the various tag handling functions
instead of the completion functions. Tag loops need rethinking anyway
and that isn't a trivial job. Discussion of possible changes to compsys
should go to zsh-workers, though.

Oliver