Dense help-like tabular combinatoric

[eugenesvk]

I'd like to be able to write in a style as close as possible to a table similar to the one -h outputs
For an example, for this

Available options:
    -s, --switch        Switch with many names
    -a, --also-arg=ARG  Argument with names
    -u, --user=USER     Custom user name
                        [env:USER1: N/A]
    -h, --help          Prints help information

I'd like to write

pub fn options() -> OptionParser<Options> {
  let switch  	= s('s').l("switch"  ).h("Switch with many names").switch();
  let arg     	= s('a').l("also-arg").h("Argument with names"   ).argument::<usize >("ARG");
  let username	= s('u').l("user"    ).h("Custom user name"      );
  // when options have extra combinators that wouldn't fit in this table, they can be added later ↓
  let username	= username.env("USER1").argument::<String>("USER");
  construct!(Options {switch,arg,username}).to_options()
}

I managed to shorten the first s('s') with use bpaf::short as s;, but then the subsequent methods on NamedArg fail
Is there a way to alias these 3 common method names to single-letter abbreviations?

[pacak]

You can make a wrapper type or a wrapper trait for NamedArg that would translate your short names to long ones, something like this:

pub trait ShortName {
    fn s(self, name: char) -> NamedArg {
        self.short(name)
    }
   ...
}

impl ShortName for NamedArg {}

[eugenesvk]

thanks, somethinkg like this seems to work

use std::str    	::FromStr;
use bpaf        	::{*, long as l, short as s, positional as pos}; // short names to allow starting builders
use bpaf::params	::{NamedArg, ParseArgument, ParsePositional};
pub trait BpafAlias { // add wrapper trait to allow using shorter .l options to continue builders
  fn s     (self, short:char        ) -> Self                                      	;
  fn l     (self, long :&'static str) -> Self                                      	;
  fn h  <M>(self, help :M           ) -> Self             where M:Into<Doc>        	;
  fn arg<T>(self, arg  :&'static str) -> ParseArgument<T> where T:FromStr + 'static	; }
impl      BpafAlias for NamedArg {
  fn s     (self, short:char        ) -> Self                                       {self.short   (short)}
  fn l     (self, long :&'static str) -> Self                                       {self.long    (long )}
  fn h  <M>(self, help :M           ) -> Self             where M:Into<Doc>         {self.help    (help )}
  fn arg<T>(self, arg  :&'static str) -> ParseArgument<T> where T:FromStr + 'static {self.argument(arg  )} }
pub trait BpafAliasPos { // ... for positional arguments
  fn h  <M>(self, help :M           ) -> Self             where M:Into<Doc>	;  }
impl<T>   BpafAliasPos for ParsePositional<T> {
  fn h  <M>(self, help :M           ) -> Self             where M:Into<Doc>         {self.help    (help )}
}

[eugenesvk]

By the way, what do you think about adding this to the docs or maybe even the crate itself? I think tabular alignment is great, and shouln't only be reserved to the -h output, but could also help on the input side

[pacak]

Crate documentation refers to the discussion page as FAQ so this question is accessible there. As for adding it do docs/crate - how are you dealing with formatting? Most of the crates I've seen are using rustfmt so tabular alignment isn't really possible without formatting things manually...

[eugenesvk]

Crate documentation refers to the discussion page as FAQ so this question is accessible there

yeah, but it's not searchable in the crate itself and not part of any tutorial. Though more importantly it's not part of the crate so you can't just use it

how are you dealing with formatting? Most of the crates I've seen are using rustfmt so tabular alignment isn't really possible without formatting things manually

Oh, I hate those simplistic formatters with a passion, so I don't use them, but also due to this might not know that there is a bunch of configs in some formatter that would allow retaining proper vertical alignment. So maybe rustfmt is isn't that simplistic? Or maybe it allows excluding a code block where you setup bpaf args (that's more likely)?

I use an elastictabstop light plugin https://packagecontrol.io/packages/ElasticTabstops for Sublime tha does the auto-alignment of those kind of tables, so adding ⭾ (notead as ⭾ symbol) in the text below would maintain the alignment of each category when e.g. you add more text to the help field or make the longer arguments longer or make the variable names longer etc.

pub fn options() -> OptionParser<Options> {
  let switch  	⭾= s('s'⭾).l("switch"  ⭾).h("Switch with many names"⭾).switch();
  let arg     	⭾= s('a'⭾).l("also-arg"⭾).h("Argument with names"   ⭾).argument::<usize >("ARG");
  let username	⭾= s('u'⭾).l("user"    ⭾).h("Custom user name"      ⭾);
  // when       ⭾ options have extra combinators that wouldn't fit in this table, they can be added later ↓
  let username	⭾= username.env("USER1").argument::<String>("USER");
  construct!(Options {switch,arg,username}).to_options()
}

[pacak]

I see. With rustfmt you can ask it to ignore certain blocks but it won't help you with alignment like that.