Skip to content
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

Support excluding a subcommand from shell completion #1335

Open
kpcyrd opened this issue Aug 27, 2018 · 6 comments
Open

Support excluding a subcommand from shell completion #1335

kpcyrd opened this issue Aug 27, 2018 · 6 comments
Labels
A-completion Area: completion generator C-bug Category: Updating dependencies E-easy Call for participation: Experience needed to fix: Easy / not much E-help-wanted Call for participation: Help is requested to fix this issue.

Comments

@kpcyrd
Copy link
Contributor

kpcyrd commented Aug 27, 2018

Feature Request Summary

I would like to exclude some subcommands from the generated shell completion. For example, the command to generate those completions is usually only used during installation and shouldn't be suggested to the user. I've managed to hide the subcommand from the help text with AppSettings::Hidden, but it's still included in the shell completion.

Expected Behavior Summary

foo <tab><tab>

All commands that are marked with AppSettings::Hidden are not suggested

Actual Behavior Summary

foo <tab><tab>

All commands are suggested.

@epage
Copy link
Member

epage commented Dec 8, 2021

@epage epage removed this from the 3.1 milestone Dec 8, 2021
@epage epage added E-easy Call for participation: Experience needed to fix: Easy / not much C-bug Category: Updating dependencies labels Dec 9, 2021
@pksunkara
Copy link
Member

Ideally, we would want this to be configured while creating the generator, but there's a lot more generation related work we would want to look at first to see if the current code is viable for future or not.

@epage
Copy link
Member

epage commented Jul 19, 2022

See also #3951 for native completion support

@fingolfin
Copy link

This issue has labels marking it as "easy" and "help wanted". But at the same time it sounds like there are open fundamental questions about whether you want it: e.g. from issue #2541 @pksunkara said Jun 17, 2021:

Need the version you are looking at because this is fixed in master.

and then in Dec 10, 2021:

I think we went back on the decision regarding this and are currently generating hidden subcommands too.

And earlier on this issue, also on Dec 10, 2021

Ideally, we would want this to be configured while creating the generator, but there's a lot more generation related work we would want to look at first to see if the current code is viable for future or not.

So... which is it, is this "easy" and "help wanted", or is there in contrast actually need for design work and experiments and what not? In other words, if someone made a PR for this, would it actually have a chance of being merged?

@epage epage added S-waiting-on-design Status: Waiting on user-facing design to be resolved before implementing E-help-wanted Call for participation: Help is requested to fix this issue. E-easy Call for participation: Experience needed to fix: Easy / not much and removed E-help-wanted Call for participation: Help is requested to fix this issue. E-easy Call for participation: Experience needed to fix: Easy / not much S-waiting-on-design Status: Waiting on user-facing design to be resolved before implementing labels Jan 15, 2024
@epage
Copy link
Member

epage commented Jan 15, 2024

Its been a couple years and I unfortunately didn't take enough notes here. I think it'd be reasonable to emulate what we can from the proposal in #3951 would be reasonable. That basically means (1) don't suggest hidden items but (2) complete within them where we can. The part we likely can't emulate is "complete the hidden item if its the only choice left".

@kpcyrd
Copy link
Contributor Author

kpcyrd commented Jan 16, 2024

For my specific use case it would be fine to have it fully excluded, without the need for (2). (however I wouldn't mind having (2)).

The subcommand is foo generate-completions ... and probably only ever used when generating a package. It's useful to have this subcommand available but the user would likely never want to invoke it themselves (if they really want to they could however).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-completion Area: completion generator C-bug Category: Updating dependencies E-easy Call for participation: Experience needed to fix: Easy / not much E-help-wanted Call for participation: Help is requested to fix this issue.
Projects
None yet
Development

No branches or pull requests

5 participants