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

[Bozhidar Batsov <bozhidar@batsov.com>]

[-- Attachment #1: Type: text/plain, Size: 5292 bytes --]

On Sat, 16 Jun 2018 at 12:07, Petko Bordjukov <bordjukov@gmail.com> wrote:

> > So... First of all, there is the variable
> ruby-flymake-use-rubocop-if-available, to satisfy the individual preference
> to turn Rubocop off.
>
> I know, I propose this to be changed to off by default.
>
> > Why would have RuboCop installed and not what to use it?
>
> Because you are working both on projects that have adopted RuboCop and
> projects that have not? In my experience the latter are more than the
> former.
>

But that's only your experience, so your comment is subjective by default.
:-)

>
> > You know this thing is configurable, right?
>
> I am aware of that, yes. I propose the default setting to be changed.
>

Or you can simply use `.dir-locals.el` per project as you just agreed that
some project use RuboCop and some don't. I haven't seen almost any projects
that don't use RuboCop (especially in a professional setting) in recent
years
and looking at its rising popularity I guess the usage will grow.

>
> > The vast majority of checks are actually pretty much community standard
> - Ruby produces only a minimal amount of lint warnings, RuboCop has
> extended linting but also a lot of code style checking functionality.
>
> I do not agree, especially with the 'pretty much community standard'
> part. If they were, they'd be part of the warnings incorporated in
> Ruby.


That's a pretty flawed reasoning. I've seen no programming language that
would incorporate this upstream, as this would tie the language development
cycle to the tooling development cycle. Linters are supposed to be
downstream projects that can evolve independently (it's the same with all
Java linters, Python linters, ES linters, etc).


> To add to that, many of the style-related warnings are in
> conflict with ruby-mode's default behaviours, which makes this issue
> even more annoying (eg hash indentation).
>

That's not true. I'm an Emacs user (obviously) and I've carefully checked
that layout config is Emacs compatible.


>
> Here is an example of the modifications necessary for even a simple
> file in a project that does not adopt RuboCop's style guide:
> https://social.petko.me/@petko/100213685659065450
>
> Again, I appreciate this feature, but do not leave it on by default --
> it will be just another bad Emacs default.
>

Flycheck has used the very same default for 5 years now and people have
been fine with this (which leads me to believe that the default is liked by
most people, as flycheck is super popular these days). You should really
understand that we can't be making decisions based on the
opinion of a single person. If there are enough reports that something's
problematic, we'd certainly try to address this, but right now it just
seems that we have your highly subjective POV.

I'm happy that flymake is following the example of Flycheck and that we're
putting some useful tools in the hands of Emacsers - that's quite different
from what we've been doing historically here and there.


>
> Cheers,
> P.
>
> On Fri, Jun 15, 2018 at 8:54 PM, Bozhidar Batsov <bozhidar@batsov.com>
> wrote:
> > Why would have RuboCop installed and not what to use it?
> >
> > I think the check is perfectly fine in its current state, especially
> given
> > the fact that you can simply disable RuboCop with the defcustom
> mentioned.
> >
> >> Since most if not all of the warnings that
> >>> Rubocop generates are not raised by Ruby I consider them not adopted by
> >>> the Ruby community by default.
> >
> > You know this thing is configurable, right? ;-) The vast majority of
> checks
> > are actually pretty much community standard - Ruby produces only a
> minimal
> > amount of lint warnings, RuboCop has extended linting but also a lot of
> code
> > style checking functionality.
> >
> > I don't really want us to check for RuboCop config files (those are
> > hierarchical and won't necessarily be in the root of your current project
> > anyways) - I think the current check + config is sufficient.
> >
> > On Fri, 15 Jun 2018 at 17:16, Dmitry Gutov <dgutov@yandex.ru> wrote:
> >>
> >> On 6/8/18 9:42 PM, João Távora wrote:
> >> > Petko Bordjukov <bordjukov@gmail.com> writes:
> >> >
> >> >> Emacs 26.1 enables flymake-rubocop by default if the rubocop
> executable
> >> >> is present in the system. Since most if not all of the warnings that
> >> >> Rubocop generates are not raised by Ruby I consider them not adopted
> by
> >> >> the Ruby community by default. Based on that, I propose that either
> >> >> using Rubocop by default is turned off, or at least a more inteligent
> >> >> per-project Rubocop detection scheme is implemented.
> >> >>
> >> > Paging Dmitry :-)
> >>
> >> So... First of all, there is the variable
> >> ruby-flymake-use-rubocop-if-available, to satisfy the individual
> >> preference to turn Rubocop off.
> >>
> >> Second, what kind of per-project detection scheme? I suppose we can
> >> abort if no ruby-rubocop-config file is found. That would certainly work
> >> for me, but would maybe conflict with the general usage of Rubocop out
> >> there (but probably not).
> >>
> >> Maybe Bozhidar has something to say on this?
>

[-- Attachment #2: Type: text/html, Size: 7038 bytes --]