New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion: Bash completion arguments only by default #173

Open
hjwylde opened this Issue Dec 8, 2015 · 10 comments

Comments

Projects
None yet
4 participants
@hjwylde

hjwylde commented Dec 8, 2015

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

This comment has been minimized.

Show comment
Hide comment
@HuwCampbell

HuwCampbell Dec 20, 2015

Collaborator

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.

Collaborator

HuwCampbell commented Dec 20, 2015

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

This comment has been minimized.

Show comment
Hide comment
@hjwylde

hjwylde Dec 22, 2015

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

hjwylde commented Dec 22, 2015

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

@HuwCampbell

This comment has been minimized.

Show comment
Hide comment
@HuwCampbell

HuwCampbell Feb 15, 2017

Collaborator

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.

Collaborator

HuwCampbell commented Feb 15, 2017

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

This comment has been minimized.

Show comment
Hide comment
@mightybyte

mightybyte Feb 23, 2017

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

mightybyte commented Feb 23, 2017

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

This comment has been minimized.

Show comment
Hide comment
@HuwCampbell

HuwCampbell Feb 23, 2017

Collaborator

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

Collaborator

HuwCampbell commented Feb 23, 2017

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

This comment has been minimized.

Show comment
Hide comment
@joeyh

joeyh Nov 9, 2017

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.

joeyh commented Nov 9, 2017

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

This comment has been minimized.

Show comment
Hide comment
@HuwCampbell

HuwCampbell Nov 15, 2017

Collaborator

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

Collaborator

HuwCampbell commented Nov 15, 2017

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

@joeyh

This comment has been minimized.

Show comment
Hide comment
@joeyh

joeyh Nov 15, 2017

joeyh commented Nov 15, 2017

@HuwCampbell

This comment has been minimized.

Show comment
Hide comment
@HuwCampbell

HuwCampbell Nov 15, 2017

Collaborator

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

Collaborator

HuwCampbell commented Nov 15, 2017

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 comment has been minimized.

Show comment
Hide comment
@HuwCampbell

HuwCampbell Nov 19, 2017

Collaborator

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

screen shot 2017-11-19 at 8 25 56 pm

Collaborator

HuwCampbell commented Nov 19, 2017

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

screen shot 2017-11-19 at 8 25 56 pm

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment