short options not parsed when longprefix is empty about args HOT 2 OPEN

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

fix_parsing_for_empty_prefixes.patch.txt

from args.

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.

from args.