Unexpected error when no options at all

[amirabiri]

I have a command that has no options and I also cancelled its help options using context:

init {
    context {
        helpOptionNames = emptySet()
    }
}

Once I do that I get a behaviour that isn't desired for me: unknown options (which are all options) are reported as NoSuchArgument instead of NoSuchOption:

my-command -g
my-command: too many arguments # I have my own error handler

Instead I expected:

my-command -g
my-command: bad option: -g # eventhough I have no options at all, that's still what I wanted

I tracked it down to the prefixes property of CommandParser - it is populated based on actual used options in splitOptionPrefixes(). It's debatable if this is desired behaviour, and I can say that at least for me that's not what I expected.

I suspect that will happen if I cancel the help options and have only short options and try to use a long one:

my-command --great-game
my-command: too many arguments # although -g exists

Perhaps allow optional direct control over what type of prefixes the user wants for options, regardless of actual options usage (and then barf if the user created a conflict). Or alternatively always assume - and -- unless the user explicitly used different prefixes.

[ajalt]

That's an interesting edge case, and I'm leaning towards implementing both of your solutions: default to - and -- if there are no options, but also allow users to specify the prefixes they want in the context.