Custom help option shows "try 'help'"

[zanieb]

When adding a custom --help option Clap changes the try_help output from

For more information, try '--help'.

to

For more information, try 'help'.

Due to the code at

clap/clap_builder/src/error/format.rs

Lines 483 to 491 in 866d7d1

	pub(crate) fn get_help_flag(cmd: &Command) -> Option<&'static str> {
	if !cmd.is_disable_help_flag_set() {
	Some("--help")
	} else if cmd.has_subcommands() && !cmd.is_disable_help_subcommand_set() {
	Some("help")
	} else {
	None
	}
	}

However, I have a global --help option. Shouldn't we still display the flag here?

[zanieb]

Here's a draft commit that would add support? zanieb@4431d99

[zanieb]

This looks like it works for my use-case in, tested in astral-sh/uv#4905

[epage]

Yes, that is basically the check we would need to do to pick up custom arguments. Ideally, a PR would be split into two commits, the first adds tests that show the current behavior and the second changes the behavior and updates the tests.

I've not updated our contributor guide yet to be more explicit about it but you can find the notes for it in my repo template: https://github.com/epage/_rust/blob/main/CONTRIBUTING.md#process

[zanieb]

I'm happy to do that, thanks!

[zanieb]

This line is actually entirely omitted for commands without subcommands, which is pretty awkward? Also my commands don't have a help subcommand so "try 'help'" is confusing in general.

[epage]

Also my commands don't have a help subcommand so "try 'help'" is confusing in general.

Are you sure? That check is re-implementing our check for auto-creating the help subcommand.

[zanieb]

I'm not sure! I'll double check — it may vary per command.

[zanieb]

Yes you're right this occurs for commands where help is not a valid subcommand because we have positional arguments.