Rubocop: More options to autocorrect as specified

[Ana06]

--auto-correc, --auto-corre, --auto-corr, --auto-cor, --auto-co and --auto-c have exactly the same behaviour as --auto-correct instead of an invalid option error.

Is this expected?

---

Steps to reproduce the problem

> rubocop --auto-cor
..........................

RuboCop version

Include the output of rubocop -V. Here's an example:

$ rubocop -V
0.51.0 (using Parser 2.4.0.0, running on ruby 2.4.2 x86_64-linux-gnu)

[ghost]

I can't say whether this is a bug or a feature but if it is a feature then it allows for lazy people to type less. :-)

I guess it may only be a problem if it were to conflict with other options.

[pocke]

I don't agree the proposal. Lazy people can use a short option such as -a and/or shell completions instead.
By this change, the option's implementation will become complicated, we should consider conflicts with other options. Sorry, I was confusing.

[bbatsov]

That's definitely a bug.

[Ana06]

@shevegen

I can't say whether this is a bug or a feature but if it is a feature then it allows for lazy people to type less.

Lazy people already have -a 😉

[jonas054]

I'm pretty sure that's a feature of Ruby's OptionParser. Long options can be abbreviated as long as they are unique. Note for example the following:

$ rubocop --fail
ambiguous option: --fail
/var/lib/gems/2.3.0/gems/rubocop-0.51.0/lib/rubocop/options.rb:19:in `parse'
/var/lib/gems/2.3.0/gems/rubocop-0.51.0/lib/rubocop/cli.rb:27:in `run'
/var/lib/gems/2.3.0/gems/rubocop-0.51.0/bin/rubocop:13:in `block in <top (required)>'
/usr/lib/ruby/2.3.0/benchmark.rb:308:in `realtime'
/var/lib/gems/2.3.0/gems/rubocop-0.51.0/bin/rubocop:12:in `<top (required)>'
/usr/local/bin/rubocop:23:in `load'
/usr/local/bin/rubocop:23:in `<main>'

Here we had both --fail-level and --fail-fast as possible completions. I for one see no problem with the current behavior. Let's keep it.

[Drenmi]

I'm pretty sure that's a feature of Ruby's OptionParser.

I suspected so as well. I don't see any strong arguments to fight against it, but can be convinced if someone thought more about it. 🙂

[Ana06]

@jonas054

I'm pretty sure that's a feature of Ruby's OptionParser. Long options can be abbreviated as long as they are unique
Here we had both --fail-level and --fail-fast as possible completions. I for one see no problem with the current behavior. Let's keep it.

Yes, it seems it is working like that, because --auto- fails, as it seems it conflicts with --auto-gen-conf. This seems unexpected to ne. It doesn't seems to be really useful as well (as you have -a) and even confusing (when using it in an script for example for the rest people who read it). As Rubocop focuses on having only one way (the best one) to do things, I would say that keeping this here doesn't have much sense. But as it is seems to come from the parser and it is something usual, I do not have a strong opinion.

[bbatsov]

I'm guessing this can be configured in OptionParser, but I'm with keeping it if it comes from there and is harmless.