Re: [Monotone-devel] "throw usage(); " or "N(); " for argument checking?

[Timothy Brownawell]

On Sun, 2009-01-04 at 11:14 -0800, Zack Weinberg wrote:
> >> > A command that does "throw usage()" gives the same result as calling
> >> > "mtn help <command>", printing full usage info to stderr, where N()
> >> > results in "mtn: misuse: <message>" on stderr and will put a note in any
> >> > debug log.
> >>
> >> As long as the <message> is maintained in case of "throw usage()", I'm
> >> fine. I dislike tools which just throw the complete usage page at me and
> >> let me figure myself. Some hint on what's wrong certainly helps. And
> >> that hint should survive, IMO.
> >
> > So I guess we should standardize on "throw usage()", but give usage a
> > what() and make the constructor take a message.
> 
> I'm dubious about printing the full usage message on any command line
> mistake.  Those are often long enough that they make the actual
> diagnostic scroll off the top of the terminal or at least be visually
> lost in a sea of chatter.

Hmm, plus there's the question of where to draw the line. Wrong number
of arguments (easy)? Missing required --options? Options that are only
required because of the number of arguments (like with 'mtn revert')?
Nonsensical combinations of options (--message with --message-file)?
Invalid argument types ('mtn approve not_a_revision_id')? Any
distinction would be somewhat arbitrary, and therefore
annoying/confusing...

> What would be really good is if we could give customized usage advice
> based on the error, e.g. currently we have
> 
> $ mtn ls
> mtn: misuse: no subcommand specified for 'ls'
> 
> but 'mtn help ls' prints a 55-line message the relevant part of which
> is in the *middle.*  It would be great if we could extract just the
> "subcommands of 'mtn ls'" part of that message and print it after the
> above diagnostic.
> 
> zw