Suggestions on help formatting

[SirNickolas]

I’m almost satisfied with the way argparse formats the help message. Just a couple of suggestions:

1. -h/--help argument should be customizable. For example, one might want to reword its description or omit --help from help (what’s the point of having it there, in the first place?). Disabling it altogether and processing it manually is not an option: -h is special-cased in the parser (no errors are issued if -h is present, and it interacts with subcommands in a complex way). I suppose the approach of ansiStylingArgument can be used here.

2. This code currently produces the following output:

   import argparse;
   
   struct Args {
       @(NamedArgument("b", "banana").Description("Description of the banana"))
       int banana;
   }
   
   mixin CLI!Args.main!((in _) { });

   Usage: myprog [-b BANANA] [-h]
   
   Optional arguments:
     -b BANANA, --banana BANANA
                   Description of the banana
     -h, --help    Show this help message and exit
   

   I’d like it to look as follows:

   Usage: myprog [-b BANANA] [-h]
   
   Optional arguments:
     -b, --banana BANANA
                   Description of the banana
     -h, --help    Show this help message and exit
   

   I.e., output a placeholder only once per set of alternatives (one BANANA at the end). Saying that several times a line just clutters the output, in my opinion. A field in the config will fit, I think.

3. You may notice in the example above that columns are separated by 4 spaces. Is it a bug? (I saw a reference to 2 spaces somewhere in the source and would indeed prefer slightly more compact layout.)

4. If epilog is empty (default), a blank line is emitted before it nevertheless. Therefore, the output of a program ends with \n\n, which feels wrong.

5. I think it would be handy if a program, when invoked incorrectly (i.e., if parsing failed), printed its one-line usage after the error message. I’d appreciate if I could just enable that behaviour with a flag in the config; however, it would even be possible to implement it outside the library if we had access to computed usage and if errorHandler wasn’t broken.