Suggestion: Bash completion arguments only by default

[hjwylde]

Right now when typing binary <TAB> optparse-applicative will auto complete to all options and arguments. I'd like to suggest changing this to auto completing only arguments, provided a HasCompleter modifier was added to them.

My reason for this is that it would help to make it clearer when auto completing for files and directories. It would still be possible to tab complete options as well by just typing the initial -.

[HuwCampbell]

Your suggestions are pretty reasonable (including #172). I'll have to think about edge cases a bit though and write some tests first. If you're interested in putting up a PR of implementation or tests, both would be appreciated. Otherwise I'll look into it a after the next minor release.

[hjwylde]

Sweet as, it's quite a busy time right now so I'll have a look into it in the new year :).

[HuwCampbell]

I'm currently doing a stint on completions and will tackle this too.

The implementation is simple enough, in that if there are any argument of command completions available, then flag and option ones will not be shown.

[mightybyte]

I'd like to add my vote for this as well. I have an option parser that includes this:

<*> argument (maybeReader $ Just . T.pack)
    ( metavar "foo"
   <> completeWith (getFooCompletions cfg)
<*> optional (argument (maybeReader $ Just . T.pack)
    ( metavar "bar"
   <> completeWith (getBarCompletions cfg)))

The "foo" argument is mandatory, but the "bar" argument is optional. However, when I hit <TAB> in the foo argument position to get completions I get the completions for both foo and bar. Since foo is mandatory, I would expect to not see any bar completions.

[HuwCampbell]

Ahh, well that one I've already fixed in #244

It's not that it's optional that's the problem, it's that it's inaccessible (it's suggesting items which aren't for the current argument position).

Also

fmap T.pack str

although that one will become nicer with #223

[joeyh]

I have a user of a program using optparse-applicative who also requested this. They said they often use command <tab> to see what files are in the current directory before starting to enter a filename, and listing a lot of options breaks that habit.

I also notice that common commands like rm and mv tab complete without options in both bash and zsh.

[HuwCampbell]

I have a working implementation of this. Still considering if I should put it behind a parser preference.

[joeyh]

Looking at the bash completions for some common command-line programs (as included in the bash-completions package in Debian), I have not found any that complete dashed options as well as filenames when completing the empty string. Most complete only filenames; a few such as cpio complete only dashed options.

Notably, the default completion used when there's no specific one for a command, which parses the command's --help to automatically try to find options, only does so when the completed string starts with a dash.

Based on that, I feel it would make sense for optparse-applicative to default to similar behavior.

-- see shy jo

[HuwCampbell]

I think for bash that's probably fine, but zsh is more flexible and allows nicer ways of showing both options and arguments together. At work we use this and it looks pretty good.

So I don't particularly want to break these more obscure use cases.

I can add a --bash-completion-* option which provides a few behaviours, and change the default bash completion script to do this (but allow it to be turned off as well).

[HuwCampbell]

This screenshot shows why I don't want to make a change like this compulsory