andrey-zherikov / argparse

Parser for command-line arguments
https://andrey-zherikov.github.io/argparse/
Boost Software License 1.0
30 stars 6 forks source link

Suggestions on help formatting #119

Open SirNickolas opened 9 months ago

SirNickolas commented 9 months ago

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.