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

Previous Next

Full log

Message #41 received at 31760 <at> debbugs.gnu.org (full text, mbox):

From: Bozhidar Batsov <bozhidar <at> batsov.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Petko Bordjukov <bordjukov <at> gmail.com>,
 João Távora <joaotavora <at> gmail.com>, 31760 <at> debbugs.gnu.org
Subject: Re: bug#31760: 26.1; ruby-mode enables flymake-rubocop by default if
 the rubocop executable exists
Date: Mon, 18 Jun 2018 17:09:00 +0300

[Message part 1 (text/plain, inline)]

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 <at> 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.
>

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.