unexpected behavior when AllowLeadingHyphen is enabled

[BurntSushi]

I understand that there is a AppSettings::AllowLeadingHyphen and that it is application wide, but is there anyway to get a more targeted approach? For example, I have flag like this:

    -e, --regexp PATTERN ...   Use PATTERN to search. This option can be
                               provided multiple times, where all patterns
                               given are searched. This is also useful when
                               searching for a pattern that starts with a dash.

Users occasionally want to use a PATTERN that starts with a -. By default, clap disallows this to make failure modes better (which I think is a great choice by default). I can permit PATTERN to start with a leading - by enabling the AllowLeadingHyphen option application wide, but if I do this, I get unexpected behavior. Here's my clap app:

extern crate clap;

use clap::{App, AppSettings, Arg};

fn main() {
    let app = App::new("ripgrep")
        .setting(AppSettings::AllowLeadingHyphen)
        .arg(Arg::with_name("path")
             .multiple(true)
             .help("A file or directory to search. Directories are searched \
                    recursively."))
        .arg(Arg::with_name("regexp")
             .long("regexp").short("e")
             .takes_value(true)
             .multiple(true)
             .number_of_values(1)
             .conflicts_with("files")
             .value_name("pattern")
             .help("A regular expression pattern used for searching. \
                    Multiple patterns may be given."))
        .arg(Arg::with_name("files")
             .long("files")
             .help("Print each file that would be searched \
                    (but don't search)."));
    println!("{:?}", app.get_matches());
}

And here's an example invocation:

$ ./target/debug/clap-hyphen a b --files c
ArgMatches { args: {"path": MatchedArg { occurs: 4, vals: {1: "a", 2: "b", 3: "--files", 4: "c"} }, "files": MatchedArg { occurs: 1, vals: {} }}, subcommand: None, usage: Some("USAGE:\n    clap-hyphen [FLAGS] [OPTIONS] [--] [path]...") }

Notice that --files is correctly detected as a flag, but it is also put into the values of the path positional argument. If I remove the AppSettings::AllowLeadingHypen option, then the behavior returns to normal and --files is no longer part of path.

I'm not sure whether this is intended behavior or not, but I can think of at least two ways you might consider solving this problem if it is indeed unintended (but of course, keeping in mind that I'm unfamiliar with the implementation!):

1. If --files is determined to be an actual flag, then it shouldn't show up in the value list of another Arg.
2. Add an ArgSettings::AllowLeadingHypen that would let me explicitly say that only values for the -e/--regexp flag can start with a leading -. (I'm guessing there's probably a good reason why this doesn't already exist though!)

Thoughts? Have I missed something?

[BurntSushi]

I wonder if there's a third option: don't permit leading hyphens in positional arguments, only in flag arguments. (Which may or may not be easier to implement, I don't know.)

[kbknapp]

Actually, now that you mention it, I do think there's a way I could easily allow targeted leading hyphens in options only. i.e. not command wide, and not in positional arguments. Let me play with an implementation real quick and see if I can get this working.

In an old implementation where this all stemmed from, it wasn't easy to determine for a single option, but this new idea may just work. Standby for updates!

[kbknapp]

Just an update, I'm still working this issue. It was a busy few days, so I didn't get near as far as I'd have liked. I should have a working PR in a few days.

[BurntSushi]

@kbknapp No worries, it's a very small matter. Thanks for looking into it at all. :-)