[PATCH]: shell-complete command

[John A Meinel]

Clint Adams wrote:
>>I'd suggest another dictionary, something like OPTION_ARGS.  Neat thing
>>is, if an option does take an argument but a name is not given in
>>OPTION_ARGS, you can use some default.  (Maybe the option name?)
>
>
> If there's going to be a 1:1 correspondence between option name and
> argument type, a dictionary for that would be redundant.  That doesn't
> allow the granularity to say, "branch -r" takes a single revision,
> "diff -r" can take a range, and "merge -r" can take a pair.  In this
> case, the real value is in presenting a description to a human;
> autocompleting integers is a bit silly.

True, but if they do:

bzr branch -r revid:mbp at sourcefrog<tab>

That might be worth autocompleting.

Remember -r can take a few different namespaces already, and that might
be increased over time. (right now we have my semi-working
implementation of "date:", "revno:", "revid:", integers are special
cased into the revno namespace, and we might make 'today' and
'yesterday' be special cased as well)

Right now the -r code is all parsed at the same point, and it is up to
the individual command to detect if it is passed too many (or too few)
revisions, and complain accordingly. (This doesn't necessarily help your
autocomplete code, though).

Also, it might be nice to have the range of revisions show up (1..1720)
when you autocomplete a number, that could tell you what range of
integers is available. (Don't complete, but show the actual range). I
don't know if that is tricky with bash autocomplete.

>
> I'm more worried about things like --format and --root; are they always
> going to take the same potential arguments regardless of subcommand?

Well, currently, the arguments to an option, all *have* to be parsed by
the same code. The dictionary maps option names to a function which will
parse them, and then the parsed result gets passed to the command using
a matching variable name.

So in some ways, yes, they all take the same potential arguments.
However, if the parser is "str" or "unicode", then the parser doesn't do
much, and it is up to the command to make sense of it. (I'm guessing for
those two, that yes, they are always treated the same).

>
> If so, this can be done more easily.
>
>

It's nice to see work done for autocompletion. Thanks for your effort.
John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050823/749dc826/attachment.pgp