Add an extra class Help or HelpProvider.

[henryiii]

This would allow customization of all components of the help messages; things like localization would be possible.

I like the idea of adding a new class that takes responsibility for the help formatting; even with no changes, this would keep App and Option a bit shorter and cleaner, which is a good thing.

[henryiii]

Idea 1:

Provide a virtual class that users could customize.

class HelpFormatter {
    std::string REQUIRED = "Required";
    
    virtual std::string help_name(Option* opt) {...}
    virtual std::string help_opts(Option* opt) {...}
    virtual std::string help_desc(Option* opt) {...}
    virtual std::string combine_help(Option* opt) {...}

    virtual std::string make_group(App* app, std::string name) {...}
    virtual std::string make_description(App* app) {...}
    virtual std::string make_usage(App* app, std::string name) {...}

    virtual std::string make_help(App* app) {...}
    virtual std::string make_help_all(App* app) {...} // NEW, exapands groups
}

The standard combine help would do:

help_name help_opts
     <space as needed>  help_desc
     <wrap/indent as needed>

Hooks could be added for the rest of the formatting, as well, like group names.

You would use it like this:

class MyHelp : public HelpFormatter {...}

app.set_help_formatter(MyHelp());

It would then be inherited by subcommands. Subclasses of App would also be able to change the default help formatter.

[henryiii]

Idea 2:

Add a class that accepts lambda functions (as std::function pointers) and variables. Then you would do:

app.get_help_formatter().set_required_name("(REQUIRED)");
app.get_help_formatter().set_combine_help([](...){...});

[henryiii]

Idea 3:

Add a template formatting language.

[lczech]

Thanks for putting together this issue!

Here are some thoughts on what would be nice to have (copied from the gitter chat):

• Customize all formatting, spaces, text highlighting etc. This is basically already possible with any of the above design ideas.
• Customize the static texts, e.g., type names like UINT, the "REQUIRED" text, "Usage: ..." etc. If those can be customized, i18n/l10n would be easier/possible.
• Long term: Have validators generate their own help text, e.g., the Range can output in [0.0, 1.0] or the like, and files and paths could output FILE instead of TEXT.