Footer callback #309
Footer callback #309
Conversation
|
This is based on the tuple PR so once that is merged this will go out of draft, or it can be extracted if that direction is not desired. |
Codecov Report
@@ Coverage Diff @@
## master #309 +/- ##
=====================================
Coverage 100% 100%
=====================================
Files 12 12
Lines 2958 3014 +56
=====================================
+ Hits 2958 3014 +56
Continue to review full report at Codecov.
|
Codecov Report
@@ Coverage Diff @@
## master #309 +/- ##
=====================================
Coverage 100% 100%
=====================================
Files 12 12
Lines 3002 3017 +15
=====================================
+ Hits 3002 3017 +15
Continue to review full report at Codecov.
|
fix incorrect parenthesis update some clang-tidy fixes mainly else after return but a few conversions from into to bool add extra newline before footer add an extra field to the extra Error add a footer callback for help operations
phlptp
force-pushed
the
footer_callback
branch
from
186930b
to
f507f3e
Compare
|
Should there be a footer and a footer callback? Can't the footer sting function just make a callback that returns the string given? Other than that it looks good. |
|
My initial thought was to do that as well, but the issue with that is footer as a string is inheritable, and I don't think you want a callback to be inheritable, So there really isn't a good resolution between them other than leaving both in place. see the gitter question a few months ago. I thought about making the callback inheritable but that has issues as well. The use case I needed it for was a cascading app, so I do some processing, then possibly depending on options called another processing app (embedded in another class) is called to process some more command line arguments. I wanted the help to actually generate help for all of them. So the solution was the footer callback (which we have been using for a couple months now), which would call the second app inside the footer callback to generate the help for the additional options inside the footer. Eventually I hope there is a cleaner way that could be done but it works pretty well for the moment when some of the help is dynamic. And I don't think that would work or even make sense if that callback were passed to the subcommands. |
If merged this PR will add a callback for footer generation, to allow extra information into the help screen that can only be generated at run time.