Suggest to use flag before subcommand if not used correctly

[torkleyy]

Suggesting to use the flag before the subcommand would make the application a bit more user-friendly.

Sample Code

App::new("myapp")
    .arg(Arg::with_name("foo")
        .long("foo"))
    .subcommand(SubCommand::with_name("bar"));

myapp bar --foo

Actual Behavior

error: Found argument '--foo' which wasn't expected, or isn't valid in this context

USAGE:
    myapp bar

For more information try --help

Expected Behavior

error: Found argument '--foo' which wasn't expected, or isn't valid in this context
      Did you mean to put '--foo' before the subcommand?

        myapp --foo bar
              ^^^^^

USAGE:
    myapp bar

For more information try --help

[kbknapp]

Apologies for the late reply, I was travelling the past week.

This would be a cool feature! I'd be willing to mentor anyone who wants to take a swing at this, although I'd change the wording slightly:

error: Found argument '--foo' which wasn't expected, or isn't valid in this context
      Did you mean to put '--foo' after the subcommand?

        myapp bar --foo
                  ^^^^^
USAGE:
    myapp bar

For more information try --help

The key code to add would be:

• Adding a variant here, to DidYouMeanMessageStyle
• Handling the new variant here
• One would probably be best off simply adding a new did_you_mean_child_args type function, which could use did_you_mean as a template of sorts.
• And finally calling this new function inside here, but using some logic like
  • if no subcommands, don't check for child args [obviously]
  • re-scan env::args_os for possible subcommands using find_subcmd!(self, arg_os) which correctly checks aliases.
  • You can get all the long version of flags and options with by Chaining the longs in Parser::flags and Parser::opts as in self.flags.iter().filter_map(|f| f.s.long).chain(self.opts.iter().filter_map(|o| o.s.long)) which could probably be passed to your did_you_mean_child_args
• Consider invocation $ prog foo --bar baz where --bar is actually a child of baz. We'd need to ensure that when re-scanning env::args_os if an arg returns that it is a valid subcommand, but does not contain --bar, we continue searching. This will prevent from accidentally checking foo for --bar which we already know doesn't exist or we wouldn't be here. We then only return the error if after exhausting the entire list we still haven't found anything. I'd also like to see how this interacts with large argvs...such as shell glob expansions that could be in the thousands or tens of thousands (although I think this would be rare case).