clap/tests/ui/help_flag_stdout.toml

bin.name = "stdio-fixture"
args = ["--help"]
status.code = 0
stdout = """
stdio-fixture 1.0

Usage:
    stdio-fixture[EXE] [OPTIONS] [COMMAND]

Commands:
    more
            
    help
            Print this message or the help of the given subcommand(s)

Options:
        --verbose
            more log

    -h, --help
            Print help information

    -V, --version
            Print version information
"""
stderr = ""
test(output): Ensure correct streams This is to prevent #3648 from happening again 2022-04-22 15:45:43 +00:00			`bin.name = "stdio-fixture"`
			`args = ["--help"]`
			`status.code = 0`
			`stdout = """`
			`stdio-fixture 1.0`

fix(help): Don't rely on ALL CAPS for headers I see them fulfilling two roles - A form of bolding - As a callback to their placeholder in usage However, it is a bit of an unpolished look and no other CLI seems to do it. This looks a bit more proefessional. We have colored help for formatting and I think the sections relation to usage will be clear enough. 2022-08-26 14:40:23 +00:00			`Usage:`
fix(help): Use Command in place of Subcommand In switching to title case for help headings (#4123), it caused me to look at "subcommand" in a fresh light. I can't quite put my finger on it but "Subcommand" looks a bit sloppy. I also have recently been surveying other CLIs and they just use "command" as well. All of them are commands anyways, just some are children of others (subcommands) while others are not (root or top-level commands, or just command). Context is good enough for clarifying subcommands from root commands. This is part of #4132 2022-08-31 02:38:37 +00:00			`stdio-fixture[EXE] [OPTIONS] [COMMAND]`
test(output): Ensure correct streams This is to prevent #3648 from happening again 2022-04-22 15:45:43 +00:00
fix(help): Use Command in place of Subcommand In switching to title case for help headings (#4123), it caused me to look at "subcommand" in a fresh light. I can't quite put my finger on it but "Subcommand" looks a bit sloppy. I also have recently been surveying other CLIs and they just use "command" as well. All of them are commands anyways, just some are children of others (subcommands) while others are not (root or top-level commands, or just command). Context is good enough for clarifying subcommands from root commands. This is part of #4132 2022-08-31 02:38:37 +00:00			`Commands:`
fix(help): Shift focus to subcommands, when present In surveying various tools and CLI parsers, I noticed they list the subcommands first. This puts an emphasis on them which makes sense because that is most likely what an end user is supposed to pass in next. Listing them last aligns with the usage order but it probably doesn't outweigh the value of getting a user moving forward. 2022-08-26 15:59:27 +00:00			`more`

			`help`
			`Print this message or the help of the given subcommand(s)`

fix(help): Don't rely on ALL CAPS for headers I see them fulfilling two roles - A form of bolding - As a callback to their placeholder in usage However, it is a bit of an unpolished look and no other CLI seems to do it. This looks a bit more proefessional. We have colored help for formatting and I think the sections relation to usage will be clear enough. 2022-08-26 14:40:23 +00:00			`Options:`
fix(help)!: Make `DeriveDisplayOrder` the default, removing it Force sorting with `next_display_order(None)` Fixes #2808 2022-07-22 20:43:49 +00:00			`--verbose`
			`more log`

test(output): Ensure correct streams This is to prevent #3648 from happening again 2022-04-22 15:45:43 +00:00			`-h, --help`
			`Print help information`

			`-V, --version`
			`Print version information`
			`"""`
			`stderr = ""`