Re: Completion function for bitkeeper?

[Danek Duvall <duvall@emufarm.org>]

On Mon, Nov 17, 2003 at 04:47:40PM +0100, Oliver Kiddle wrote:

> You're not doing something wrong so much as different.

People have been telling me this all my life.  ;-)

> Firstly, the most common case is that there are no options other than
> compadd options to get mixed up with so having $expl added is what is
> wanted.

Fair enough; I certainly understand that.

> You wanted the compadd options after your own extra option because it
> made it easier to find your option--it would always be the first one.
> That made your helper function simpler but puts the onus on the
> calling functions to get the options in the right order.

Well, not just that it would be easier to find my option, but that my
option would be findable at all.

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.

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

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

One answer I can think of is to avoid the use of command-line flags
entirely, and just have two different functions.  Three probably -- one
is the function as it currently is, and two wrapper functions that call
the the first either with or without a flag.  Then they'd be
distinguished by different names.  A global shell variable is another
answer.  But these just seem kludgey to me.

> If you found a Unix program which had two independent and unrelated
> options -a and -b and the program couldn't cope with them being
> specified in the order -b followed by -a, you wouldn't think it was
> very good would you?

Of course not, but that's not the problem at hand.  It's not ordering
that's the problem, it's overlapping namespaces.  And by the time my
function sees the result, the overlap is no longer undoable.  It's like
merging image layers in GIMP or Photoshop -- you can't reconstruct the
layers from the merged result, so you don't know which pixels came from
which layer, so you've lost information.

Danek