Tag completition doesn't return filelist and does not honor argument number or directories

[con-f-use]

I'm using the docopt-wordlist utility with a python script of mine. It does not return filenames as suggestions. Here is an example:

#!/usr/bin/python
"""
Minimal demonstration of docopt-wordlist not giving file names, repeating
arguments, where it shouldn't and failing to offer file and dir completion.

Usage:
  exfl.py --help
  exfl.py ([--test=<arg>] FILE)
"""
from docopt import docopt
arguments = docopt(__doc__)

Expected behavior in bash shell session:

confus@confusion:~$ exfl.py                 # [TAB][TAB]
--help  --test  file1.txt  file2.txt  dir1/
confus@confusion:~$ exfl.py --test          # [TAB][TAB]
file1.txt  file2.txt  dir1/
confus@confusion:~$ exfl.py --test --       # [TAB][TAB] no completion expected

confus@confusion:~$ exfl.py --test di       # [TAB] 
confus@confusion:~$ exfl.py --test dir1/    # [TAB][TAB]
subdir1  subdir2  subfile1.txt  subfile2.txt

Actual (wrong) behavior in bash shell session:

confus@confusion:~$ exfl.py                 #[TAB][TAB]
--help  --test                                  # files and dirs missing here
confus@confusion:~$ exfl.py --test          # [TAB][TAB] dir or file expected but completes to:
confus@confusion:~$ exfl.py --test --       # [TAB][TAB] allows infinite repetition of options and doesn't give a file or dir as it should
--help  --test                                  # files and dirs missing here
confus@confusion:~$ exfl.py --test di       # [TAB] completes to "dir1" as should but
confus@confusion:~$ exfl.py --test dir1     # [TAB][TAB] does not give subdirectories of "dir1" because the slash ('/') is missing
--help  --test

Also seems to print the "Usage: ..." message again, when complete -F _docopt_wordlist_commands exfl.py is set in .bash_completion instead of complete -F _docopt_wordlist exfl.py.

[BurntSushi]

Well, firstly, I think your usage is wrong. For a flag to have an argument, you need to explicitly say so in an Options: section.

Otherwise, yeah, there is a lot wrong with the current tab completion support. It could be a lot better. This is a case where getting a little (what's there) was very easy, but making it perfect will probably require quite a bit of work. (This includes extending the current implementation of Docopt to expose more details of the usage string, which probably won't happen until I rewrite the internals.)

[BurntSushi]

With that said, I would certainly welcome improvements to the existing bash completion scripts. This is really the first time I've ever tried to setup tab completion in bash, so I'm sure I fumbled it a bit.

[con-f-use]

Very well. I'm not an expert in tab completion either and hardpressed for time, but I'll see what I can do.

I think your usage is wrong. For a flag to have an argument, you need to explicitly say so in an Options: section.

I don't think so. Only Usage: exfl.py --test <arg> without the equal sign is ambigous. There, one coundn't tell wheter --test is a flag, i.e. it takes NO argument, followed by a positional argument, or it REQUIRES the <arg> argument. The docopt documentation isn't too specific about it, saying:

--input=ARG is equivalent to --input ARG

But then (allegedly) contradicting itself by stating that they are at least different in the following respect:

Note, writing --input ARG (opposed to --input=ARG) is ambiguous, meaning it is not possible to tell whether ARG is option's argument or positional argument. In usage patterns this will be interpreted as option with argument only if option's description (covered below) for that option is provided. Otherwise it will be interpreted as separate option and positional argument.

I take that to mean, if only if the '=' is missing and you don't want the option to be a flag, will you need an Optuions: section. At least that is how it SHOULD be, because the variant with an equal sign IS unambigous.

[keleshev]

For a flag to have an argument, you need to explicitly say so in an Options: section.

This is required only in ambiguous cases like --input <arg>, but not required in unambiguous cases like --input=<arg>.

[BurntSushi]

My bad! Thanks for the correction. :-)