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

[Petko Bordjukov <bordjukov@gmail.com>]

> So, you're basically saying that it's a big deal to write class documentation and that it's just some noise (!!!) and that some default line length (which is 80 by default in so many languages and you can obviously change) is some big problem.

No. I am not saying that. I am saying that Emacs is by default
enforcing an unofficial and intrusive (as I illustrated -- every
single line of the simple data model is underlined because there is no
class documentation) style guide on all files in projects,
_irregardless if they've chosen to adopt said style guide_. This is
the key here. I am not commenting on the RuboCop config and if it
should raise such warnings. If I were, I'd have filed an issue with
RuboCop. As per this, I will not address your comments on whether
writing class documentation and adhering to 80 chars per line is 'a
big deal'.

> Frankly, as far as I'm concerned you're making some counter arguments to your points. I acknowledge that some aspects of the default config are controversial and that's going to addressed soon, but I think that also applies to most non-trivial lint tools. In the end of the day the value you get out of project consistency always outweighs some small initial investment in a tweaking some config.

I am not arguing for/against general linter use or specifically
RuboCop use, so I'm not sure this is relevant in this discussion.
Maybe you could clarify?

> > > 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. :-)

I was not opining -- I was giving you an example why you'd have
RuboCop installed without wanting to use it in a particular project.

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

While this is actually a subjective opinion, an objective one is that
pretty much each project that uses RuboCop has their own version of a
style guide. Why then should the default RuboCop style guide be
enforced by default for projects that have not adopted RuboCop at all?

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

Though it is somewhat outside this discussion, I am really not making
this up: https://social.petko.me/@petko/100216195543129951

Cheers,
P.

On Sat, Jun 16, 2018 at 12:36 PM, Bozhidar Batsov <bozhidar@batsov.com> wrote:
> Btw, I forgot to comment on the screenshot. So, you're basically saying that
> it's a big deal to write class documentation and that it's just some noise
> (!!!) and that some default line length (which is 80 by default in so many
> languages and you can obviously change) is some big problem.
>
> Frankly, as far as I'm concerned you're making some counter arguments to
> your points. I acknowledge that some aspects of the default config are
> controversial and that's going to addressed soon, but I think that also
> applies to most non-trivial lint tools. In the end of the day the value you
> get out of project consistency always outweighs some small initial
> investment in a tweaking some config.
>
> On Sat, 16 Jun 2018 at 12:31, Bozhidar Batsov <bozhidar@batsov.com> wrote:
>>
>>
>>
>> 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?