On Mon, Nov 16, 2009 at 6:35 AM, Eric Holscher wrote:
> Hey all,
>
> What I did
>
>
> First thing I did was write tests for the current behavior[1]. No tests were
> written for the original commit, so if nothing else, these tests should be
> commited. The link there works for the current environment, then I added a
> few more tests that test my changes as well.
This bit is super-mega-awesome. Thanks for taking the time to do this
- I've just committed it.
> After that, I implemented a basic API for declaring a completion in a
> Command class[2]. I will describe here the implemented API. I'm hoping that
> people have some ideas about the correct way to implement this.
...
> Please let me know what you all think, and what I have missed. Implementing
> these changes would resolve a lot of the special casing in the bash
> completion, and turn it into a real API that is useful for management
> command authors. I think that this is a big win. Bash completion is one of
> those things that is super useful, but a damned pain to implement.
> Abstracting it this way would make a lot of our commands grow bash
> completion I would bet.
I'm agreed that this is one of those things that is hard to implement,
but very useful when it is.
I'm also agreed that it would be great to be able to abstract the task
of command completion to inside the command definition itself. Having
the list of app-name-accepting commands hardcoded is an annoying
limitation.
However, I'm not completely sold on your API proposal. The second
version is certainly better than the first (the dict approach is way
off), but I agree with Yuri - this problem is a bit more complex than
your API allows for.
For example, what if the subcommand 'awesome' allows one set of
arguments, and 'sweet' allows a different set? What if the order of
arguments is significant? What if the order of arguments with relation
to command flags is significant (e.g., any command given after the -x
option will be handled differently)?
At the very least, I suspect that the completion method would need to
be given some sort of context on which to base completions. This would
need to include (but isn't necessarily limited to) the previous
command line arguments that have been parsed, or some analogous
description of the command line context.
Alternatively, the completion command could pass back a grammar of
some kind that described the order in which arguments can be accepted,
and providing callbacks to describe how each token in the grammar can
be completed. In some ways, the syntax you have proposed follows this
direction - but the grammar you have provided isn't expressive enough
to cover anything but really simple examples. For example, I'm not
sure how you would express the current completion syntax for sqlall
(which allows any number of arguments, each of which must be an app)
in a way that is unambiguous to your ljworld example which appears to
allow exactly 3 arguments.
Of course, the risk here is that you end up re-implementing the whole
of optparse just to enable the parsing of individual options - which
isn't really an appealing option.
Yours,
Russ Magee %-)
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=.
