This feature is definitely a help to us for shipping products where some features are unlikely to be used by the end user (but we use them internally), ideally there would be a help all added after this lands that would allow displaying those flags as well

👍

I understand the motivation for a feature like this, but this could also be accomplished by checking for an environment variable and conditionally adding flags in the source (e.g. looking for INTERNAL_FLAGS=1).

@jszwedko perhaps this is not how you design your applications, but I would assume for most the app.Run() is their first entry point, to establish the environment within which the application will execute, creating a separate pre-run step that also establishes the environment seems like duplication of effort

@termie sure, but it doesn't need to be. The main entry point is always main and I don't think it is improper to vary the commands, flags, etc. that are allowed based on the environment the application is running under. Every feature adds cost to the library, so I'm just trying to consider the alternatives.

Oh wow, i should have seen this PR before i just submitted - #201 .. damn! , how quickly will this be merged?

Improved upon #201 with filtering flags at higher level than 'templates' so that we don't end up with odd formatting issues. This way we don't also have to keep IsHidden() or IsNotHidden() exported functions. Please review..

Also by default --generate-bash-completion flag is never printed along with help.

+1