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

Configure help subcommand to print long form #2435

Closed
pwinckles opened this issue Apr 6, 2021 · 5 comments · Fixed by #2440
Closed

Configure help subcommand to print long form #2435

pwinckles opened this issue Apr 6, 2021 · 5 comments · Fixed by #2440
Labels
A-help Area: documentation, including docs.rs, readme, examples, etc... E-help-wanted Call for participation: Help is requested to fix this issue. 💸 $5
Milestone

Comments

@pwinckles
Copy link

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 of git help init, git init -h, and git 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

@pksunkara pksunkara added this to the 3.1 milestone Apr 6, 2021
@pksunkara pksunkara added 💸 $5 A-help Area: documentation, including docs.rs, readme, examples, etc... D: easy E-help-wanted Call for participation: Help is requested to fix this issue. labels Apr 6, 2021
@pwinckles pwinckles changed the title Configure help subsommand to print long form Configure help subcommand to print long form Apr 6, 2021
@reaganmcf
Copy link
Contributor

I would like to work on this 😄

@reaganmcf
Copy link
Contributor

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 utils::compare_output() but that seems to be for errors.

(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)
    );
}

@ldm0
Copy link
Member

ldm0 commented Apr 10, 2021

@reaganmcf compare_output() is not only for errors. It can be used for both stdout and stderr. There is nothing wrong with you test.

@reaganmcf
Copy link
Contributor

@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

@ldm0
Copy link
Member

ldm0 commented Apr 10, 2021

@reaganmcf Hmm, check this?:

    assert!(utils::compare_output(
        m,
        "myprog help test",
        SUBCOMMAND_HELP_LONG_FORM_USING_BEFORE_HELP,
        false)
    );

epage added a commit to epage/clap that referenced this issue Feb 11, 2022
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
epage added a commit to epage/clap that referenced this issue Feb 11, 2022
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
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... E-help-wanted Call for participation: Help is requested to fix this issue. 💸 $5
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants