Cannot print the description text for groups/subcommands

[ruffel]

When attempting to print the help text for a subcommand, any description that was set for it does not get printed.

If I define a subcommand using the lyra::command class and attempt to set a description for the subcommand.

const auto on_success = [this](const lyra::group& group) {
    if (showHelp_) {
        std::cout << group << std::endl;

        return;
    }
};

lyra::command("subcommand", on_success)
    .add_argument(lyra::help(showHelp_)
        .description("This is a description."))
    .add_argument(lyra::opt(dryRun_)
                  ["--dry-run"]
                  ("Parse the command line but don't execute the command."));

If I call <exe> subcommand --help I would expect the description text "This is a description." to appear between the USAGE and OPTION, ARGUMENTS for the subcommand, but what I get is:

PS D:\test> .\test.exe subcommand --help
USAGE:
  subcommand { [-?|-h|--help] [--dry-run] }

OPTIONS, ARGUMENTS:
  subcommand

  -?, -h, --help
  --dry-run               Parse the command line but don't execute the command.

The reason for this is that when calling get_description_text it checks if the current class is a group and skips printing the description. arguments.hpp

This seems to be done so that if --help is called on the top level command, the description for every subcommand is not printed. However, there does not seem to be a way to allow the description text to go through when printing the help text for a subcommand.

[grafikrobot]

You use the help method on the command itself to get the effect you want, AFAIK. As:

lyra::command("subcommand", on_success)
    .help("This is a description."))
    .add_argument(lyra::help(showHelp_)
    .add_argument(lyra::opt(dryRun_)
                  ["--dry-run"]
                  ("Parse the command line but don't execute the command."));

Does that work for you?

[ruffel]

Apologies for the late response. I stopped working on the project that required a CLI parser so haven't been tracking this. The snippet does appear to work to resolve for the original issue.