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: 10382 bytes --]

Well, seems this is one of those discussions that can go on forever and no
one can really make a solid enough argument to support their point of view.

As Emacs 26.1 is out this can't really be changed for about a year - Joao
made a good point here. Frankly, I don't really care at all whether you
decide to
change this or not. I don't use flymake and I don't plan to use it, so it's
all the same to me. I like the current state of affairs, as I'm passionate
about exposing more people to good programming style,
but I don't really have time to waste on this debate. I'd rather spend my
time elsewhere fixing some actual problems.

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

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

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