Alternative multiple prefixes; no prefix dupe in help; custom colors

[eugenesvk]

I'd like to experiment with a more ergonomic though unconventional syntax, as far as I understood from the docs it might be possible as bpaf is flexible enough (e.g., you can use + per this example https://docs.rs/bpaf/0.9.3/bpaf/_documentation/_2_howto/_02_xorg/index.html), but then also has some limits re. colors, so thought I'd ask here first which of the following is feasible within bpaf (and any pointers on how to do that in a simpler way would be appreciated)

Roughly the scheme would be as follows:

• have , as a prefix vs. the pinky-murdering - and --
  • but retain the - for compatibility
• for the , prefix the short option concatenation should be disabled (this would allow not requiring ,, for long options), but then you could concatenate without spaces like ,s,d,g,long
  • the - prefix should retain whatever the current defaults are, so it would still be -sdg --long or -s -d -g --long

Then also a bunch of custom formatting options:

• the help file should list prefixes only once in a separate message
  so instead of

Available options:
    -s, --switch        Switch with many names

it should be

Available options prefixed with either - or ,
  Short	Long  	Description
  s    	switch	Switch with many names

• the help should allow custom colors per prefix, so , and - should be colored differently from the text (I tried .help("text".blue().bold()) from the colored crate to test for a specific argument's help message, but then got a trait bound bpaf::Doc: From<ColoredString> error)
  • (is there a way to override color scheme bright-color?)
• the help should allow custom colors per argument, e.g., if you want to deemphasize -h you could make it NOT have any colors or if you want to emphasize
• similarly, instead of signifying optionality with the metadata taking more space than data [-s], allow using maybe underlines or at least a different color emphasis (I'd prefer to include an extra short legend)
• The usage example should only use the alternative , notation, - should only be mentioned in the description mentioned above

[pacak]

I'd like to experiment with a more ergonomic though unconventional syntax

There are two ways you can go about it - preprocessing arguments as you get them from the OS before feeding to bpaf and making custom parsers.

• With preprocessing you get args from the OS, convert it to a vector and replace ,h with -h, splitting ,a,b into -a, -b, etc and pass it to OptionParser::run_inner. It won't help much with custom help renderer and there are a few gotchas if you want to support non-utf arguments. But this approach would work with most of the other parsers.
• With custom parser you make something using any that would accept both let's say -v and ,v and produces impl Parser<bool>. You'll probably need a few helpers - for switches and for arguments. There's also ParseAny::anywhere that you will need for that. Positional/commands can stay as is. Xorg and dd examples show how to do that, for argument you'll also use ParseCon::adjacent. You can control how --help will show it with metadata, might need to do something like having two option parsers inside of it - one to parse it, one to print it. You won't get autocomplete or some of the improved error messages since bpaf can't know what function function will accept. Problem with that - it won't be able to parse combined items - (say parsing ,a,b into a pair of bools) unless you cover all the combinations yourself, but it will work fine with them separately.
• You can also use combination of those two methods - mostly splitting blocks of ,a,b into ,a, ,b and letting custom parsers based on any to do the work.

Then also a bunch of custom formatting options:
Some of them should be doable with ParseAny::metavar, custom headers are not possible at the moment. You can add your own with group_help, but original ones will be still around.
To get custom colors you should avoid bpaf colorization and use ANSI codes inside strings passed to ParseAny::metavar and Parser::custom_usage. There's no way to globally replace things like [-s] with colors (and it might not work well since they can be arbitrarily nested) but custom_usage can help you.

There's no way to change --help parser to accept ,,help, you'll have to handle it manually.

Once basic things are in place - compositions should just work.

So most of this is doable with varying amount of effort.

[eugenesvk]

thanks for the explanations!

gotchas if you want to support non-utf arguments

are these the OsString vs str kind of gotchas? (ideally I'd like to avoid having to think about those complications since great libs like bpaf have already thought about them :))

mostly splitting blocks of ,a,b into ,a, ,b and letting custom parsers based on any to do the work.

would this approach avoid the non-utf gotchas?

You won't get autocomplete or some of the improved error messages since bpaf can't know what function function will accept

that's unfortunately a big downgrade in experience

To get custom colors you should avoid bpaf colorization and use ANSI codes inside strings passed to ParseAny::metavar and Parser::custom_usage.

So the nicer syntax item.underline().bold() isn't possible even if I use the same owo-colors you use?

[pacak]

are these the OsString vs str kind of gotchas?

Yes.

would this approach avoid the non-utf gotchas?

If you use just any and give up on being able to parse ,a,b same as ,a ,b - it would.

that's unfortunately a big downgrade in experience

Library makes some assumptions about what it parses but gives an option to parse much more.

So the nicer syntax item.underline().bold() isn't possible even if I use the same owo-colors you use?

You can, but you'll have to convert item.underline().bold() to String yourself. Possibly with some helpers I guess.