Add setting to forbid numeric option names

[jwodder]

I'm using lexopt to write a command that supports negative numbers and dates (i.e., things starting with - and a digit) as arguments. If the user doesn't pass -- before such an argument, then lexopt treats, say, -1234 as the short option -1, and I have to use Parser::optional_value() to get the rest of the argument, append it to the -1, and parse the result. This works, but it's a little inconvenient, and it doesn't forbid arguments like -v1234.

I therefore request that lexopt add some setting (likely through a ParserBuilder) for not treating a hyphen followed by a digit as a short option. If you think this isn't sufficiently minimalist for lexopt, that's OK with me; I just thought I'd throw the idea out there.

[blyxxyz]

The current suggested workaround for this uses try_raw_args(), see examples/nonstandard.rs. (For your use case you'd want to get rid of .strip_prefix('-')?.)

But it's a little unwieldy and it's not too obvious and you're not the first one to want to handle -123 specially. So maybe it deserves more attention.

At a minimum I can call it out in the README as an example. (It's linked from the "Command line syntax" section but the description is on the cryptic side.)

A dedicated feature could be a setting or it could even be something else. Some considerations:

• tail also handles -123, but it treats it as synonymous with -n 123, i.e. an option with a positive integer value; you treat it as a positional argument with a negative value. It would be nice to support both cases in one go.

• 13 is another pending request to add a setting. Whatever configuration system we pick should work for that case too.

  • For that case it would be more powerful to add a method to Parser instead of introducing a ParserBuilder type, so you can have different settings for different options.
• Would a negative number be considered an option by Parser::values()? (This is the only method besides next() that tries to guess whether an argument is an option or a value based on its content.)
  • For your use case it should count as a value, but for tail it should count as an option.

Since there's a full workaround I'm not in a hurry to implement it but I will keep this issue open. Thanks for bringing it up!