-
-
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
Configure help subcommand to print long form #2435
Comments
I would like to work on this 😄 |
I have made a little bit of progress on this (added the setting and started integration tests). However, I am wondering how I would go about writing integration tests for this. Reading over the code base, I found (I am going to reformat and run clippy before I send the PR, so ignore that for now) Here is an example of one of my tests, what is the best way to do this? #[test]
fn subcommand_help_shows_long_form_with_setting_using_before_help() {
let m = App::new("myprog")
.setting(AppSettings::SubcommandHelpShowsLongForm)
.subcommand(App::new("test")
.before_help("short form help message")
.before_long_help("long form help message"));
assert!(utils::compare_output(
m,
"help test",
SUBCOMMAND_HELP_LONG_FORM_USING_BEFORE_HELP,
false)
);
} |
@reaganmcf |
@ldm0 Currently the test above is pacnicking. Here is is the output: ---- subcommand_help_shows_long_form_with_setting_using_before_help stdout ----
thread 'subcommand_help_shows_long_form_with_setting_using_before_help' panicked at
'called `Result::unwrap_err()` on an `Ok` value: ArgMatches { args: {}, subcommand: Some(SubCommand { id: test, name: "test", matches: ArgMatches { args: {}, subcommand: None } }) }',
tests/utils.rs:36:19 |
@reaganmcf Hmm, check this?: assert!(utils::compare_output(
m,
"myprog help test",
SUBCOMMAND_HELP_LONG_FORM_USING_BEFORE_HELP,
false)
); |
Like was said in clap-rs#2435, this is what people would expect. While we should note this in a compatibility section in the changelog, I do not consider this a breaking change since we should be free to adjust the help output as needed. We are cautious when people might build up their own content around it (like clap-rs#3312) but apps should already handle this with `--help` so this shouldn't be a major change. We aren't offering a way for people to disable this, assuming people won't need to. Longer term, we are looking at support "Actions" (clap-rs#3405) and expect those to help customize the flags. We'll need something similar for the `help` subcommand. Fixes clap-rs#3440
Like was said in clap-rs#2435, this is what people would expect. While we should note this in a compatibility section in the changelog, I do not consider this a breaking change since we should be free to adjust the help output as needed. We are cautious when people might build up their own content around it (like clap-rs#3312) but apps should already handle this with `--help` so this shouldn't be a major change. We aren't offering a way for people to disable this, assuming people won't need to. Longer term, we are looking at support "Actions" (clap-rs#3405) and expect those to help customize the flags. We'll need something similar for the `help` subcommand. Fixes clap-rs#3440
Please complete the following tasks
I have searched the discussions
I have searched the existing issues
Describe your use case
The
help
subcommand prints the short help form, and I would like to configure it to print the long form instead.The long form is more inline with my expectations of what the
help
subcommand should return. For example, compare the output ofgit help init
,git init -h
, andgit init --help
. At least on my system, the subcommand produces the long form; not the short form.Describe the solution you'd like
Ideally this would be configurable via AppSettings.
Alternatives, if applicable
No response
Additional Context
No response
The text was updated successfully, but these errors were encountered: