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

From: Petko Bordjukov <[email-masked]>
Date: Sat, 16 Jun 2018 22:54:19 +0300

> I'd just like to chime in briefly with two points:

Thank you for the advice, João. If it's decided on not flipping the
default, I will probably implement the change for myself. Considering
many projects that have adopted RuboCop specify their own
configuration in their roots, I'd probably check and enable in such
cases and leave the rest for .dir-locals.el.

Cheers,
P.

On Sat, Jun 16, 2018 at 6:32 PM, João Távora <[email-masked]> wrote:
> Petko Bordjukov <[email-masked]> writes:
>
>> Again, I appreciate this feature, but do not leave it on by default --
>> it will be just another bad Emacs default.
>>
>
> I'd just like to chime in briefly with two points:
>
> * IMO Petko has a point: Emacs is expected to be conservative about
>   tooling support: unless some optional tool is widely adopted, optional
>   things are made... err... optional.  Of course this is for some value
>   of "widely adpted"; one that the maintainer of said tool probably has
>   a particularly generous conception of, ehehe.
>
>   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.
>
> * 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?
>
> João
>
>