display format of bool flags
Closed this issue · 4 comments
Quoting a suggestion from @bmoyles in #26:
Anecdotally (I don't have data to back this up, unfortunately), bool options by convention are assumed false if not specified on the command line and are true if present. If one wants a bool that defaults to true and is toggled false via an option, the conventions I've seen most often are "--no-option" or "--without-option." I do like the option of being explicit and showing the default true/false if the situation or interface makes sense, but prefer "--option" to imply false by default and true if present and "--no-option" to imply true by default, false if not present. Do you agree and is this something you'd be interested in a PR for?
I'm thinking aloud here, so bear with me:
- Not showing the default value for boolean flags can already be done with the
HideValuefield, but it has to be set on all the boolean flags, which is a PITA - If this is to be implemented, would it be a good idea to make it configurable (an opt-in), maybe on on the app or command level, in order to not upset the existing users of the lib ?
- Wouldn't a more general solution, based on using templates to generate and display the help message be, well, more general and extensible in the long run ?
I was originally thinking at a minimum, exposing it through the helper functions cmd.BoolOpt() and cmd.BoolArg() would be useful, but then... why not expose all of the struct fields through those helpers (but then you're just about as verbose as building the struct and passing it to cmd.Bool())
Configuring the default behavior for default visibility at the app-level (or even the Command-level) seems like a better solution, but I'm curious about your template-based suggestion. Are you suggesting expanding the role of Spec to control this, or making cmd.printHelp() template-driven and configurable?
Are you suggesting expanding the role of Spec to control this, or making cmd.printHelp() template-driven and configurable?
Precisely :)