bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Petko Bordjukov
Subject: bug#31760: 26.1; ruby-mode enables flymake-rubocop by default if the rubocop executable exists
Date: Sat, 16 Jun 2018 22:47:48 +0300

> 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 <address@hidden> 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 <address@hidden> wrote:
>>
>>
>>
>> On Sat, 16 Jun 2018 at 12:07, Petko Bordjukov <address@hidden> 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 <address@hidden>
>>> 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 <address@hidden> wrote:
>>> >>
>>> >> On 6/8/18 9:42 PM, João Távora wrote:
>>> >> > Petko Bordjukov <address@hidden> 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?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]