-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Multiple subcommand categories / help_heading
s
#1553
Comments
@pksunkara we were just talking about whether |
Looks like I didn't need to create an issue for what we were talking about. |
The question we need to resolve with this is how to handle naming
Maybe if we changed the behavior so that
This would be a breaking change and one that doesn't offer a transition path with deprecations. Any other ideas for how we could do this? |
help_heading
s
Bikeshedding on the name to make it more clear,
One concern with combining the arg and app help heading setting in one function is what to do when they have a common heading? How do we display the help? |
One option I had been considering that I forgot until your post is I worry people will just refer to what help headings as groups or categories, so using a |
Yeah, I think I am trying to convey that the function sets help heading for both args and subcommands. Maybe it's better if we just divide them into |
So to summarize the solution:
I guess the downside to the name |
This clarifies the intent and prepares for other functions doing the same, like `next_display_order`. This will then open us to name `subcommand_help_heading` and `display_order` similar. The deprecation is waiting on 3.1. This is part of clap-rs#1807 and clap-rs#1553.
#3414 changed |
Think I'm going to push this out. In working on this, I realized a problem we'd have is how to set the help heading for the implicit help subcommand and help/version flags. |
Until clap-rs/clap#1553 is fixed, I don't think we can do better than alphabetical order (without a lot of work).
Until clap-rs/clap#1553 is fixed, I don't think we can do better than alphabetical order (without a lot of work).
Been a year now, has there been any movement on this? |
We would love this feature as well... only being able to have one group for commands is very limiting and makes for a bad UI for the user. |
I am trying to implement it. I am wondering where to place command that do not belong to any groups and the "commands" heading.
meaning placing commands not belonging to any group on top.
and what to do when heading is provided, but all commands are grouped:
Any thoughts? |
I'd recommend doing what we do for Options. However, before going to far down this, how do you plan to handle the |
Currently a CommandGroup would be added, and it can have optional heading (group won't show a name for group unless you specify heading). |
I would like this to be consistent with arguments. If there is a reason we should change arguments, we should have that as a separate conversation. That said, that doesn't say how users can use this with a built-in command ( |
Ok, makes sense. Arguments print heading and a list of ungrouped arguments on top, no heading if there are no ungrouped arguments.
With current implementation I have, it treats it as any other command. By default it is ungrouped. You can put it into a group if you wish (well, you can via builder, not sure about derive). Seems intuitive to me. |
Also, you specify a help heading. Argument groups are for associations and not visualization.
How do you put |
WIP, but if anyone is interested: https://github.com/Fiedzia/clap/tree/command-groups |
Feature Request Summary
It would be nice to be able to have multiple subcommand groupings.
Sample
An example of what I mean can be found at BrettMayson/HEMTT#195
The text was updated successfully, but these errors were encountered: