[PATCH]: shell-complete command

[Clint Adams]

> 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).

No, so that information needs to be duplicated elsewhere or moved higher up.
Where should it go?

> 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.

It's not tricky with zsh.  I have little knowledge of bash.

> 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).

"str" or "unicode" is much too generic to be helpful; one can't offer
all possible strings as potential completion matches.