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

Multiple subcommand categories / help_headings #1553

Open
BrettMayson opened this issue Sep 27, 2019 · 18 comments
Open

Multiple subcommand categories / help_headings #1553

BrettMayson opened this issue Sep 27, 2019 · 18 comments
Labels
A-help Area: documentation, including docs.rs, readme, examples, etc... C-enhancement Category: Raise on the bar on expectations M-breaking-change Meta: Implementing or merging this will introduce a breaking change. S-waiting-on-design Status: Waiting on user-facing design to be resolved before implementing
Milestone

Comments

@BrettMayson
Copy link

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

@CreepySkeleton CreepySkeleton added A-help Area: documentation, including docs.rs, readme, examples, etc... C: subcommands 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. C-enhancement Category: Raise on the bar on expectations labels Feb 1, 2020
@pksunkara pksunkara removed the W: 3.x label Aug 13, 2021
@epage
Copy link
Member

epage commented Dec 8, 2021

@pksunkara we were just talking about whether App::subcommand_help_heading should be supported in a way to allow individual subcommands to have their own help heading like args.

@pksunkara
Copy link
Member

Looks like I didn't need to create an issue for what we were talking about.

@epage
Copy link
Member

epage commented Dec 9, 2021

The question we need to resolve with this is how to handle naming

App::help_heading applies to future args

App::subcommand_help_heading globally applies to subcommands as if you called App::help_heading at the start and never called Arg::help_heading.

Maybe if we changed the behavior so that

  • App::help_heading applied to future args and subcommands
  • App::subcommand_help_heading applied to the current subcommand like Arg::subcommand
    • We'd have to deal with what to name App::subcommand_value_name because that was mean to be parallel to the current behavior

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?

@epage epage changed the title Multiple subcommand categories Multiple subcommand categories / help_headings Dec 9, 2021
@epage epage added S-waiting-on-design Status: Waiting on user-facing design to be resolved before implementing and removed P4: nice to have 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 labels Dec 9, 2021
@pksunkara
Copy link
Member

pksunkara commented Dec 10, 2021

Bikeshedding on the name to make it more clear,

  • App::help_heading => Command::help_heading_group
  • App::subcommand_help_heading => Command::help_heading (similar to Arg::help_heading)

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?

@epage
Copy link
Member

epage commented Dec 10, 2021

One option I had been considering that I forgot until your post is Command::next_help_heading.

I worry people will just refer to what help headings as groups or categories, so using a _group suffix I don't think will convey the intent of "all following are being grouped under the this heading" (which I'm assuming is the intent of the suggestion).

@pksunkara
Copy link
Member

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 args_help_heading and subcommands_help_heading. But I think next_help_heading is better than help_heading_group definitely.

@epage
Copy link
Member

epage commented Dec 10, 2021

So to summarize the solution:

  • App::help_heading would
    • Be renamed App::next_help_heading
    • Will also apply to subcommands
  • App::subcommand_help_heading would be removed
  • App::help_heading would be added and acts like Arg::help_heading but for subcommands
  • We would need to add tests to make sure next_help_heading on a derive(Subcommand) behaves as expected.

I guess the downside to the name next_help_heading is in derives. This is also getting me thinking that maybe we should provide some more flexibility by renaming our attribute from clap to clap::app and clap::arg. This would allow a user to set app settings in the middle of the derive. If that idea sounds like it has potential, I'll create a separate issue for further discussion.

@pksunkara pksunkara added the M-breaking-change Meta: Implementing or merging this will introduce a breaking change. label Dec 10, 2021
@epage epage added this to the 4.0 milestone Dec 14, 2021
epage added a commit to epage/clap that referenced this issue Feb 8, 2022
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.
@epage
Copy link
Member

epage commented Feb 8, 2022

#3414 changed App::help_heading -> App::next_help_heading. The rest of the work is reserved for clap 4.

@epage
Copy link
Member

epage commented Sep 7, 2022

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.

@epage epage modified the milestones: 4.0, 5.0 Sep 7, 2022
martinvonz added a commit to martinvonz/jj that referenced this issue Mar 7, 2023
Until clap-rs/clap#1553 is fixed, I don't
think we can do better than alphabetical order (without a lot of
work).
martinvonz added a commit to martinvonz/jj that referenced this issue Mar 7, 2023
Until clap-rs/clap#1553 is fixed, I don't
think we can do better than alphabetical order (without a lot of
work).
@milesj
Copy link

milesj commented Sep 2, 2023

Been a year now, has there been any movement on this?

@YamatoSecurity
Copy link

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.

@Fiedzia
Copy link

Fiedzia commented Nov 8, 2024

I am trying to implement it. I am wondering where to place command that do not belong to any groups and the "commands" heading.
Option 1: commands not belonging to any group go to top

Commands:
cmd1 ...
cmd2 ...

Group1:
cmd3
cmd4

Group2:
cmd5
cmd6

meaning placing commands not belonging to any group on top.
Alternatively, They could go to bottom. This makes more sense to me,
but maybe not to other people.

Group1:
cmd3
cmd4

Group2:
cmd5
cmd6

Commands:
cmd1
cmd2

and what to do when heading is provided, but all commands are grouped:

Commands:

Group1:
cmd3
cmd4

Any thoughts?

@epage
Copy link
Member

epage commented Nov 8, 2024

I'd recommend doing what we do for Options.

However, before going to far down this, how do you plan to handle the help subcommand? That is why I stopped this work before. In clap v3, we had a bunch of specific helpers for overriding builtin arguments (--help, --version) and we simplified things a lot (improving performance and reducing binary bloat) by only supporting users disabling the built-in argument and providing it themself. Currently, there isn't a way to do the same thing with the help subcommand. My assumption is that we need to solve that problem first before we add custom help headings for subcommands.

@Fiedzia
Copy link

Fiedzia commented Nov 8, 2024

Currently a CommandGroup would be added, and it can have optional heading (group won't show a name for group unless you specify heading).

@epage
Copy link
Member

epage commented Nov 8, 2024

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 (help). As I said, there is likely something we need to solve there first.

@Fiedzia
Copy link

Fiedzia commented Nov 8, 2024

I would like this to be consistent with arguments.

Ok, makes sense. Arguments print heading and a list of ungrouped arguments on top, no heading if there are no ungrouped arguments.

that doesn't say how users can use this with a built-in command (help)

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.

@epage
Copy link
Member

epage commented Nov 9, 2024

Ok, makes sense. Arguments print heading and a list of ungrouped arguments on top, no heading if there are no ungrouped arguments.

Also, you specify a help heading. Argument groups are for associations and not visualization.

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.

How do you put help under a custom heading?

@Fiedzia
Copy link

Fiedzia commented Nov 13, 2024

WIP, but if anyone is interested: https://github.com/Fiedzia/clap/tree/command-groups

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-help Area: documentation, including docs.rs, readme, examples, etc... C-enhancement Category: Raise on the bar on expectations M-breaking-change Meta: Implementing or merging this will introduce a breaking change. S-waiting-on-design Status: Waiting on user-facing design to be resolved before implementing
Projects
None yet
Development

No branches or pull requests

7 participants