bug#31760: 26.1; ruby-mode enables flymake-rubocop by default if the rubocop executable exists

[Dmitry Gutov <dgutov@yandex.ru>]

On 6/16/18 6:32 PM, João Távora wrote:

>    There was little discussion on this before 26.1 because it was all
>    kinda rushed, because Dmitry is the maintainer of ruby-mode, and most
>    importantly, nobody objected (much less I, who welcomed the enthusiasm
>    for using the new API).  So even though Emacs 26.1 is a month old, the
>    conservative stance is now to keep default.

To be clear, I only did the most simple thing (and indeed, nobody 
objected). So anybody who doesn't like the behavior in 26.1, you're 
welcome to try out pretest versions. That's what they're for.

That said, I'm totally fine with adding a new value for 
ruby-flymake-use-rubocop-if-available (like `auto'), and make it the 
default. Because I personally have also been hit by it turning on in 
projects where it's not exactly needed. Like Ruby Stdlib, certain gems, 
etc. And older projects, yes.

I suggested the following already. Nobody responded to it so far:

"I suppose we can abort if no ruby-rubocop-config file is found."

Meaning, if there is no .rubocop.yml is any directory containing the 
current file, RuboCop is not used.

The main reasons I'm putting this off is avoiding calling 
locate-dominating-file twice, while keeping the simplicity of having two 
different diagnostic functions available for user use, is a bit tricky.

> * On the practical front, I personally dislike defcustom and prefer
>    having flymake backends separate, so instead of having
>    ruby-flymake-auto checks the defcustom, I advise Petko to use a
>    directory-local variable in the project configuring
>    flymake-diagnostic-functions to either ruby-flymake-simple or
>    ruby-flymake-rubocop, i.e. some .dir-locals.el containing this
> 
>       (...
>        (ruby-mode . (...
>                      (flymake-diagnostic-functions ruby-flymake-simple)
>                      ...))
>        ...)
>    
>    Won't this suffice as a per-project (almost zero) configuration?

That still leaves the question of a reasonable default. But if you ask 
me, removing the custom variable a making the "auto" behavior "always 
on" will also be good.