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