-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
feat: add command headings feature #6183
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
base: master
Are you sure you want to change the base?
Conversation
2b3d6c7 to
8c43bdc
Compare
|
Please clean up the commits for how they should be reviewed and merged.
|
45ae543 to
503ebfd
Compare
These commits are still around |
|
Also, be sure to ping me when force-pushing; github doesn't send notifications for it. |
503ebfd to
758234f
Compare
|
@epage dropped the commits and force pushed |
|
Please clean up commits for how they should be reviewed and merged and not for how this was implemented |
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
3c9f66a to
b985eb4
Compare
|
@epage Amended and test for flatten introduced; changes introduced to ensure test passes |
| // Commands under custom headings | ||
| if !custom_headings.is_empty() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change is overall a lot more complicated than I would have expected and I'll likely need to dig into this a lot further to better understand how inherent the complexity is or isn't before we're able to move forward.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The objective is to preserve the order in which the flattened commands are set out both in the usage and the commands sections so that commands are grouped within their custom headings.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is a fair point. If people rely on the help headings to logically group their commands, then consistently using that order elsewhere can make sense. There can still be room for discussing whether it is worth it or not. Most likely, we'll need to whittle away at other complexity first to see how much of an impact it really makes.
As for the other complexity, in each case where we are dealing with custom help headings, we are duplicating all of the underlying logic rather than folding the custom and built-in heading cases together, making this more ripe for bugs. This code also special cases help which will make it diverge in order compared to anything else and seems like a potential feature independent of this work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, two issues here:
- Special casing of help
- Need to refactor the similar/same processes to reduce duplication
There is another concern I had last night and that is whether there are any other artefacts that are caused by the feature.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is another concern I had last night and that is whether there are any other artefacts that are caused by the feature.
What do you mean?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is another concern I had last night and that is whether there are any other artefacts that are caused by the feature.
What do you mean?
That there would be some other interaction from the help_heading API - I produced a more comprehensive set of tests (all the helps tests with subcommand with a help_heading added) and only found a couple of problems with the flattened versions. One fixed and the other I am still working on.
- add tests for subcommand headings feature - include tests for single and multiple help headers - add test for hiding commands header - add test for mixed standard and custom headers - add test case to verify that mixed headings are flattened correctly - shuffled order in multiple command test - add support for subcommand help headings - display subcommands under their respective headings in help output - only display heading if subcommand has `help_heading` set - Set order for custom headings (as found) - write commands in order under headings in order - update usage and help templates to display in custom headings order - introduce `complex_app_with_help_heading` function - similar to `complex_app` but includes `help_heading` - Test subcmds with `help_heading` - Update tests to include the custom heading in the expected output. - extract the logic for writing a flattened subcommand to a function
a602450 to
d9e586b
Compare
Implementing issue #1553
Scope of this PR
The objective for this PR is to provide a facility for the user to place their commands under a custom header to allow the grouping of commands such as might be seen in
git --help.The PR will not implement
CommandActionwhich would be required to permit the user to replace thehelpcommand with a custom userhelpcommand which could be place under a custom header. The user can placehelpunder a custom header by amending the default title usingCommand::subcommand_help_headingplacing the help command and the updated section at the top of the list of commands.The will not change the scope of the
Command::next_help_headingto include processing for commands as this is a breaking change.Design Statements
Command::next_help_headingto include subcommandsCommand::subcommand_help_headingCommandAction