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

[Bozhidar Batsov]

I guess you can just look for .rubocop.yml in the root of the project. That's not a precise way to infer if someone wants to use RuboCop, but it should be good enough for most people (relatively few people have global RuboCop configs). 

I wonder if it won't be good to have a lint-mode only option as well - generally `rubocop --lint` will show only things that are important to fix, but it's much nicer than `ruby -w`. So, I'd still use rubocop for linting if RuboCop is installed and use it for everything else only when the project has some project config. 

On Mon, 18 Jun 2018 at 17:02, Dmitry Gutov <dgutov@yandex.ru> wrote:

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.