+1

@acesuares I was able to get this working in the enum branch. I'd be interested to get your feedback before merging it into master. I would also like to use the same logic to select unambiguous substrings of tasks to select unambiguous substrings of enums. What do you think about that? Good or bad idea?

FYI, here's my main use case: sferik/x-cli@9d9d38c. In this case, resolving unambiguous substrings to their full values would be nice but I could imagine cases where you'd want an enum to be a strict constraint. Maybe this should be another flag on on string types. Something like strict_enum which could be true or false (probably true by default)?

Fine work, is it really needed to do all the extra parsing, or just get the first version out the door, the one that does nothing else then take the full strings (no aliases, no unambiguity) and then maybe later make it more versatile? Don't be mad, just asking. I couldnt follow the link to your use case, could you paste it again? thx

Would the use of :enum => %w(apple banana) also automatically create a :banner => "apple|banana" by default?

    DATABASE_OPTIONS = %w(sqlite mysql)
    method_option :database, :aliases => "-d", :default => DATABASE_OPTIONS.first, :banner => DATABASE_OPTIONS.join('|'), :desc => 'specify development database'

The default banner for a string option is the name of the option. The possible values (as well as the default value) are displayed in the second column, below the description. Like this:

That is also a good solution, +1 for what it's worth. Could you send me the use case, in my browser it show up as sferik/x-cli@9d9d38c. and if I click it, it opens an email...

Ah, that appears to be a bug in GitHub-Flavored Markdown. Here's the full link: sferik/x-cli@9d9d38c

Personally I would go for the strict implementation of enum in this case. I think typing

t -d s -p m -t p

is less useful then

t --development sqlite --production mysql --test postgresql
t -d sqlite -p mysql -t postgresql

and it there really a need to be able to do this:

t --deve sql --pr my --t pos

But, if it can do all that, well, that's good, there is no such thing as too much features...

On second thought, debugging a script when someone adds an option that makes a previously unambiguous option ambiguous might be problematic...

This pull request fails (merged 0150b86 into 5523b5f).