Derive doc clap ordering for multiple Clap

[pickfire]

Fix #2527

[pksunkara]

Please write a separate test and test the full help output instead of this partial assertion in another test.

[pickfire]

@pksunkara Fixed

[epage]

btw I think this will break GlobalVersion because it has to be set before everything else

Personally, I would recommend we move all app settings set via attributes to be in IntoApp only, not allowing inheriting them through flatten. I personally find that confusing that pulling in args is also pulling in settings.

[pksunkara]

Can you please expand on what you mean? I am a little bit confused.

[epage]

Can you please expand on what you mean? I am a little bit confused.

When we derive Args, we put all settings in augment_app rather than into_app, so when an Args is flattened into an Args, settings are applied from both with the last flattened Args winning. This PR changes the evaluation order.

Example: Originally clap_cargo::Features had a doc string saying how to flatten it into your Args. A structopt update came out and suddenly its developer-focused doc-string started winning, being exposed in --help and I had to remove it so the real about would get passed to clap and then the user.

imo we should instead move some of these to into_app and not allow inheriting certain settings. This is especially true with clap3 where clap_cargo will be updated to derive Args and not Clap. In this case, conceptually, an Args shouldn't be providing application settings (subcommand handling is an example exception and is an artifact of clap's design)

[pksunkara]

Can you please create an issue with an example failure and proposal on how to fix it?