add a utilities for shell autocompleters to hook into as well as support for extending completion info

[GoogleCodeExporter]

support for shell autocompletion is quite pleasant,

please add helpers to ease supporting it

Original issue reported on code.google.com by ronny.pfannschmidt on 12 Jan 2010 at 1:09

[GoogleCodeExporter]

I'm open to patches for this kind of thing, but I don't know anything about how 
to do
this.

Original comment by steven.b...@gmail.com on 15 Jan 2010 at 12:18

[GoogleCodeExporter]

I haven't tested it but for optparse, there seems to be this interesting module:

http://furius.ca/optcomplete/

Original comment by seb.binet@gmail.com on 28 Jan 2010 at 7:55

[GoogleCodeExporter]

and I just noticed this package on PyPI:
http://pypi.python.org/pypi/genzshcomp

(which seems to already handle argparse)

Original comment by seb.binet@gmail.com on 20 Feb 2010 at 10:25

[GoogleCodeExporter]

Original comment by steven.b...@gmail.com on 28 Feb 2010 at 10:09

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

There seem to be a number of ways to go about this:
- add a way of generating standalone shell completion scripts;
- add a special option to the program to perform shell completion;
- write a separate program that loads the target program and then extracts the 
arguments.

The first option could allow the completion script and the program to get out 
of sync
with each other (one is upgraded without the other).  It would also not be 
possible
to have computed options (e.g. you might want to show a list of branches in a 
version
control system).  

The second option would require the target program to accept some magic
command/argument/environment variable, and that seems like a hack to me.

The third option would the program to export the argument parser and make sure 
that
they check that __name__ == "__main__" before doing much more than constructing 
the
argument parser.  These seem like reasonable limitations, so that would be my
preferred option.  

With regards to bash completion
(http://www.gnu.org/software/bash/manual/bashref.html#Programmable-Completion), 
a
shell function or program can be called to determine what the possible options 
are
for completing the current argument.  The current commandline and position in 
the
commandline are avaliable in an environment variable, the possible completions 
are
returned in an environment variable or on stdout.  

To support this argparse would have to be able to parse this (partial) command 
line
and then give a list of the possible remaining arguments.  This shouldn't be 
too hard
for option names (e.g. --option, -o), subcommands, and values with choices.  It 
is
slightly more problematic for cases like the branch names example given 
earlier, and
even worse for things like completion of remote filenames (again, a version 
control
system might want to do this).  For these more awkward cases I imagine an extra
option to add_argument might be required.  

I imagine that most (if not all) of this functionality can be implemented 
internally
to argparse.  This would ensure that the argparse code does not have a whole 
new API
to support.  The argparse code should probably be written so that any shell can 
use
it given a few lines of shell script.  

I'm going to see if I can implement this (or at least make some progress), so do
shout if there are any problems with this proposal.  

Original comment by adoak...@gmail.com on 29 Apr 2010 at 9:04

[GoogleCodeExporter]

Looks like this is going to require some changes to the code structure - we 
have to
be prepared to accept incomplete sets of arguments without calling sys.exit. 
Subcommands are probably the most problematic area here as they call the parser
recursively.  

Are you open to shuffling some of the code round a bit so that error handling 
is not
so closely tied to the parser?  I'm also tempted to see if the subcommand can be
parsed without a recursive call.  These changes will probably not 
(intentionally)
change the behavior of the code and would be sent as separate patches.  

Original comment by adoak...@gmail.com on 29 Apr 2010 at 10:12

[GoogleCodeExporter]

I'm definitely open to shuffling code around, and removing the recursive call 
for subcommands would probably resolve a parse_known_args issue. I'm going to 
close this issue here though, and if you create patches, could you file them 
with new issues at bugs.python.org?

Original comment by steven.b...@gmail.com on 23 Jul 2010 at 12:42

• Changed state: WontFix