Please support a feature to omit all help and messages

[joshtriplett]

For the purposes of reducing binary size, I'd love to have a new default feature flag for clap (that projects could then disable) that would omit generated --help and all friendly error/constraint messages, and minimize error reporting to just "Invalid arguments" or similar. That would help for embedded use cases that may want to reduce the sizes of binaries used in scripting, without regard to human invocations of those binaries.

[CreepySkeleton]

Related to #1485

[CreepySkeleton]

Closing in favor of #1365

[Dylan-DPC-zz]

This may be a side effect of that but not directly related. Reopening

[Rua]

I would like this as well, but supported as a runtime option instead of a feature flag, so that it can be enabled or disabled on a case-by-case basis.

[ldm0]

I would like this as well, but supported as a runtime option instead of a feature flag, so that it can be enabled or disabled on a case-by-case basis.

@Rua This issue is mainly about reducing binary size. If you just wanna control the help message emission in the runtime, the right-now approach is using try_get_matches to get a result and control the output by yourself.

[pksunkara]

Postponing this for later than 3.0 because we need design on how to divided the existing help, error messages, usage etc.. into separate feature flags.

[epage]

#2914 would unblock code-generating a display-agnostic(wrapping, styling) help message

So breaking this down, parts we can trim down

• Simpler error messages
• Static help (App::override_help)
• Code-genned formatted help with re-rendering the help (built on [modular] Decouple help format from help generation #2914)
• Non-smart usage
• Static usage (App::override_usage)

The main question I have is how should we divide this up among feature flags without overwhelming people (with too many flags). For example, a user could want to provide codegenned formatted help but still get all of the other nice features. Next would be the bike shedding over the names.

To get the conversation started, I'll start with

• helpgen
  • Without App::override_help, no --help flag is generated
• detailed-errors
  • includes smart usage, people have to disable helpgen to get rid of smart usage

With that said, how we divide things up I think depends partly on the cost of each feature. For example, if smart usage is more expensive, then maybe that should be broken out into its own feature flag. Or if detailed errors isn't too expensive, maybe we don't provide it. So I am assuming whatever decision we come up is a guideline and the implementer would need to measure the results and adapt accordingly.