short options not parsed when longprefix is empty

[culyun]

If I setup an ArgumentParser with both short and long options AND the long option prefix is empty (""), the short options are never parsed, eg.

args::ArgumentParser parser("This is a test program.", "This goes after the options."); parser.ShortPrefix("-"); parser.LongPrefix(""); parser.LongSeparator("="); args::ValueFlag<int> counter(parser, "integer", "The counter value", {'c', "counter"});
This works ok..

./test counter=3

But this does not..

./test -i 3

[culyun]

Here's a hacked together patch that can be applied to de4db87

fix_parsing_for_empty_prefixes.patch.txt

[Taywee]

That's tough. I'd prefer unambiguous parsing in most cases. An empty long prefix will always be matched, because long options take precedence over short. Options aren't required to be alphanumeric, and -v could be an actual long-option name (matching the empty-string long prefix). That said, I see why you'd want the behavior you'd expect, because usually that's the way you'd really want it to behave.

Why the restriction on long separator containing both whitespace and non-whitespace characters? I don't see a reason to prevent the long separator from being any arbitrary string, as silly as it might be. If somebody is doing something ridiculous like having their long separator : so they can specify options with 'optionname: value', that would break it.