Disambiguate breaks options which are prefixes of others

[munchhausen3435]

Discovered the following bug today. I haven't really explored it, but below is a seemingly minimal example:

import Options.Applicative

data Opt = A | B

opts :: Parser Opt
opts = flag' A (long "test") <|> flag' B (long "test1")

main :: IO ()
main = () <$ customExecParser (prefs disambiguate) (info opts mempty)

Let's call this program test. Running test --test yields:

Invalid option `--test'

Did you mean one of these?
    --test
    --test1

Usage: test (--test | --test1)

However, test --test1 executes just fine. Furthermore, replacing main by

main = () <$ execParser (info opts mempty)

parses either option just fine.

I've tried this with the latest versions (0.16.0.0 and 0.16.0.1) and also hopped back to 0.15.0.0 just to see if there was any difference.

[HuwCampbell]

Thanks for the report.

When disambiguation is turned on, one can just type the prefix of an option, and if there's just one option which the user could be part way through typing, then that's what's selected. Here, "test" is a prefix of both options, so it's considered ambiguous. It's a bit ironic.

So I think that's pretty undesirable behavior. I tend not to use the disambiguation system very much myself as once bash completion is turned on it doesn't really save users' typing, and in some ways it's a bit surprising.

I'll have a think as to whether there's a nice solution.

[munchhausen3435]

I figured this was the case. And I agree with you about the disambiguation system. I had it turned on since I was just testing options for some code via stack exec -- ... and wanted to save some key-strokes; hence why I noticed the bug.

Whether or not there's a reasonable fix, it would probably be a good idea to explicitly mention this limitation in the documentation. Currently, this limitation is implied by the phrasing (since here "test" is not an unambiguous prefix), though I had jumped to the assumption that the disambiguation system would be smart enough to understand that there was an exact match.

[pcapriotti]

It should be possible to fix this by returning more precise match information from optMatches and using it when disambiguating. I'm not sure this is worth the extra complexity, though.

[munchhausen3435]

Fair enough. I don't need it fixed for any of my applications since I generally don't use disambiguation. I just wanted to bring this to your attention. At the very least, I recommend adding this caveat to your documentation, though

[pcapriotti]

I've added a note to the README. I'll close the issue for now, as I don't think it's worth complicating the code too much over what is essentially correct (albeit counter-intuitive) behaviour. We might revisit this in the future if and when the parsing code gets an overhaul.