multicall & nested commands help - unwanted parent command name concatenation

[RustyJoeM]

Hello,

I am trying the multicall feature with default help templates (none set by myself).
It seems to address most of the former problems for REPL mode usage.
There is still one item that seems to break the "shell command" / "repl mode" help formatting.

Root CLI help is perfectly fine:

cli$ help
USAGE:
    <SUBCOMMAND>

SUBCOMMANDS:
    dump      ...
    send      ...
    help      Print this message or the help of the given subcommand(s)

Same applies for root subcommand output:

netconf-cli$ help dump
dump

USAGE:
    dump <SUBCOMMAND>

SUBCOMMANDS:
    ...

Problem shows at one more nesting level - first line of help output seems to do the "binary name/root command"
and sub-command concatenation - text shown is dump-lock, expected something like dump lock, or lock only):

netconf-cli$ help dump lock
dump-lock

USAGE:
    dump lock <TARGET>

ARGS:
    <TARGET>    [possible values: running, candidate]

Types used to derive the above behavior with clap 3.1.15:

#[derive(Parser, Debug)]
#[clap(multicall(true), disable_help_flag(true))]
pub struct RootArgs {
    #[clap(subcommand)]
    pub command: RootCommand,
}

#[derive(Subcommand, Debug)]
pub enum RootCommand {
    #[clap(subcommand, display_order(1))]
    Dump(NetconfCommand),
    #[clap(subcommand, display_order(1))]
    Send(NetconfCommand),
}

pub enum NetconfCommand {
    Lock {
        #[clap(possible_values(["running", "candidate"]))]
        target: Datastore,
    },
    ...
}

[epage]

#1431 is the issue for display names without hyphens. At the moment, we are looking at resolving that by just allowing users to override the display name for each subcommand. Until clap v4, this will require a help_template to use. With v4, it will be the default.

I also wonder about the utility of showing the name in the help. I think it fits best when also showing the version but when that isn't shown, it seems a bit redundant. We can't conditionalize that yet though users can provide their own template. Also, in some cases, people would want only the top-level command shown while in others also the subcommand.

#1334 might also be of interest in some subcommands.

[epage]

Just wanted to add that you can programmatically set the display_name so it isn't a big pain to annotate every subcommand.

Parser::parse is an inherent function that glues two generated functions together, CommandFactory::command and FromArgMatches::from_arg_matches. if you replace the call to parse with the direct calls to those functions, you could write a recursive function that descends into all of the subcommands and generates custom display names for each one.

The one annoyance is that we use the owned builder pattern rather than the mut-ref one, so you can't directly call the functions. You'd need to std::mem::swap with a dummy version, call the builder function, and then std::mem::swap back. If that is looking to be a pain, we can add a set_display_name like we have a set_bin_name that uses a &mut self instead.