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

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

[Petko Bordjukov]

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.

Steps to reproduce:

1. Have Ruby and the Rubocop gem installed.
2. Edit a file in ruby-mode
3. Enable flymake-mode
4. See flymake wranings from Rubocop

In GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30)
 of 2018-05-29 built on juergen
Windowing system distributor 'The X.Org Foundation', version 11.0.12000000
System Description:	Arch Linux

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS NOTIFY
ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS
GTK3 X11 MODULES THREADS LIBSYSTEMD LCMS2

Important settings:
  value of $LC_MONETARY: bg_BG.UTF-8
  value of $LC_NUMERIC: bg_BG.UTF-8
  value of $LC_TIME: bg_BG.UTF-8
  value of $LANG: en_GB.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Ruby

Minor modes in effect:
  rspec-verifiable-mode: t
  robe-mode: t
  subword-mode: t
  yard-mode: t
  autopair-mode: t
  diff-hl-mode: t
  hl-line-mode: t
  rainbow-delimiters-mode: t
  yas-global-mode: t
  yas-minor-mode: t
  whitespace-mode: t
  flymake-mode: t
  ruby-block-mode: t
  global-auto-complete-mode: t
  auto-complete-mode: t
  projectile-rails-global-mode: t
  projectile-rails-mode: t
  inf-ruby-minor-mode: t
  global-rbenv-mode: t
  global-magit-file-mode: t
  magit-file-mode: t
  diff-auto-refine-mode: t
  magit-auto-revert-mode: t
  auto-revert-mode: t
  global-git-commit-mode: t
  async-bytecomp-package-mode: t
  shell-dirtrack-mode: t
  ido-ubiquitous-mode: t
  ido-vertical-mode: t
  ido-everywhere: t
  fic-mode: t
  erc-list-mode: t
  erc-menu-mode: t
  erc-autojoin-mode: t
  erc-ring-mode: t
  erc-networks-mode: t
  erc-pcomplete-mode: t
  erc-netsplit-mode: t
  erc-track-mode: t
  erc-match-mode: t
  erc-hl-nicks-mode: t
  erc-button-mode: t
  erc-fill-mode: t
  erc-stamp-mode: t
  erc-irccontrols-mode: t
  erc-noncommands-mode: t
  erc-move-to-prompt-mode: t
  erc-readonly-mode: t
  delete-selection-mode: t
  show-paren-mode: t
  cl-old-struct-compat-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
/home/ignisf/.emacs.d/elpa/flim-20180328.1624/hex-util hides /usr/share/emacs/26.1/lisp/hex-util
/home/ignisf/.emacs.d/elpa/flim-20180328.1624/md4 hides /usr/share/emacs/26.1/lisp/md4
/home/ignisf/.emacs.d/elpa/flim-20180328.1624/ntlm hides /usr/share/emacs/26.1/lisp/net/ntlm
/home/ignisf/.emacs.d/elpa/flim-20180328.1624/sasl-digest hides /usr/share/emacs/26.1/lisp/net/sasl-digest
/home/ignisf/.emacs.d/elpa/flim-20180328.1624/sasl-cram hides /usr/share/emacs/26.1/lisp/net/sasl-cram
/home/ignisf/.emacs.d/elpa/flim-20180328.1624/hmac-md5 hides /usr/share/emacs/26.1/lisp/net/hmac-md5
/home/ignisf/.emacs.d/elpa/flim-20180328.1624/hmac-def hides /usr/share/emacs/26.1/lisp/net/hmac-def
/home/ignisf/.emacs.d/elpa/flim-20180328.1624/sasl hides /usr/share/emacs/26.1/lisp/net/sasl
/home/ignisf/.emacs.d/elpa/flim-20180328.1624/sasl-ntlm hides /usr/share/emacs/26.1/lisp/net/sasl-ntlm

Features:
(shadow sort mail-extr emacsbug sendmail smex vc-git rspec-mode ac-robe
robe etags xref project cap-words superword subword yard-mode autopair
diff-hl vc-dir ewoc vc vc-dispatcher hl-line rainbow-delimiters
elec-pair image-file yasnippet windmove whitespace flymake-rust
flymake-easy flymake-proc flymake warnings rvm ruby-block
auto-complete-config auto-complete popup projectile-rails rake f
inflections inf-ruby ruby-mode-expansions ruby-mode smie projectile grep
compile ibuf-ext ibuffer ibuffer-loaddefs cl rbenv multiple-cursors
mc-hide-unmatched-lines-mode mc-separate-operations
rectangular-region-mode mc-mark-pop mc-mark-more mc-cycle-cursors
mc-edit-lines multiple-cursors-core rect web-mode-expansions web-mode
disp-table magit-obsolete magit-blame magit-stash magit-bisect
magit-remote magit-commit magit-sequence magit-notes magit-worktree
magit-tag magit-merge magit-branch magit-reset magit-collab ghub
url-http tls gnutls url-gw nsm url-auth url url-proxy url-privacy
url-expand url-methods url-history url-cookie url-domsuf url-util
mailcap let-alist json map magit-files magit-refs magit-status magit
magit-repos magit-apply magit-wip magit-log magit-diff smerge-mode
diff-mode magit-core magit-autorevert autorevert filenotify
magit-process magit-margin magit-mode git-commit magit-git magit-section
magit-utils crm subr-x magit-popup log-edit message rmc puny rfc822 mml
mml-sec epa derived epg gnus-util rmail rmail-loaddefs mm-decode
mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util
ietf-drums mail-prsvr mailabbrev mail-utils gmm-utils mailheader
pcvs-util add-log with-editor cl-extra help-mode async-bytecomp async
shell server dash ido-completing-read+ memoize s cus-edit cus-start
cus-load minibuf-eldef ido-vertical-mode ido fic-mode edmacro kmacro
expand-region text-mode-expansions er-basic-expansions
expand-region-core advice expand-region-custom erc-list erc-menu
erc-join erc-ring erc-networks erc-pcomplete pcomplete comint ansi-color
ring erc-netsplit erc-image image-dired image-mode dired dired-loaddefs
url-queue browse-url erc-track erc-match erc-hl-nicks color erc-button
erc-fill erc-stamp wid-edit easy-mmode erc-goodies erc erc-backend
erc-compat format-spec thingatpt pp delsel paren finder-inf
commander-autoloads eimp-autoloads flymake-yaml-autoloads
logito-autoloads mark-multiple-autoloads rx shift-text-autoloads
smooth-scroll-autoloads vline-autoloads info package easymenu epg-config
url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache url-vars seq byte-opt gv bytecomp
byte-compile cconv cl-loaddefs cl-lib time-date mule-util tooltip eldoc
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win
x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote dbusbind inotify lcms2 dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty
make-network-process emacs)

Memory information:
((conses 16 407364 38576)
 (symbols 48 44516 2)
 (miscs 40 500 592)
 (strings 32 122750 4102)
 (string-bytes 1 3488793)
 (vectors 16 47453)
 (vector-slots 8 881674 22598)
 (floats 8 302 453)
 (intervals 56 677 27)
 (buffers 992 17))

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

[João Távora]

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

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

[Dmitry Gutov]

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?

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

[Bozhidar Batsov]

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

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

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

[Petko Bordjukov]

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

> You know this thing is configurable, right?

I am aware of that, yes. I propose the default setting to be changed.

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

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.

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?

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

[Bozhidar Batsov]

[-- 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 --]

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

[Bozhidar Batsov]

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

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

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

[Petko Bordjukov]

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

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

[Bozhidar Batsov]

[-- 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 --]

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

[João Távora]

Petko Bordjukov <bordjukov@gmail.com> writes:

> Again, I appreciate this feature, but do not leave it on by default --
> it will be just another bad Emacs default.
>

I'd just like to chime in briefly with two points:

* IMO Petko has a point: Emacs is expected to be conservative about
  tooling support: unless some optional tool is widely adopted, optional
  things are made... err... optional.  Of course this is for some value
  of "widely adpted"; one that the maintainer of said tool probably has
  a particularly generous conception of, ehehe.

  There was little discussion on this before 26.1 because it was all
  kinda rushed, because Dmitry is the maintainer of ruby-mode, and most
  importantly, nobody objected (much less I, who welcomed the enthusiasm
  for using the new API).  So even though Emacs 26.1 is a month old, the
  conservative stance is now to keep default.

* On the practical front, I personally dislike defcustom and prefer
  having flymake backends separate, so instead of having
  ruby-flymake-auto checks the defcustom, I advise Petko to use a
  directory-local variable in the project configuring
  flymake-diagnostic-functions to either ruby-flymake-simple or
  ruby-flymake-rubocop, i.e. some .dir-locals.el containing this

     (...
      (ruby-mode . (...
                    (flymake-diagnostic-functions ruby-flymake-simple)
                    ...))
      ...)
  
  Won't this suffice as a per-project (almost zero) configuration?

João
  

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

[Petko Bordjukov]

> I'd just like to chime in briefly with two points:

Thank you for the advice, João. If it's decided on not flipping the
default, I will probably implement the change for myself. Considering
many projects that have adopted RuboCop specify their own
configuration in their roots, I'd probably check and enable in such
cases and leave the rest for .dir-locals.el.

Cheers,
P.

On Sat, Jun 16, 2018 at 6:32 PM, João Távora <joaotavora@gmail.com> wrote:
> Petko Bordjukov <bordjukov@gmail.com> writes:
>
>> Again, I appreciate this feature, but do not leave it on by default --
>> it will be just another bad Emacs default.
>>
>
> I'd just like to chime in briefly with two points:
>
> * IMO Petko has a point: Emacs is expected to be conservative about
>   tooling support: unless some optional tool is widely adopted, optional
>   things are made... err... optional.  Of course this is for some value
>   of "widely adpted"; one that the maintainer of said tool probably has
>   a particularly generous conception of, ehehe.
>
>   There was little discussion on this before 26.1 because it was all
>   kinda rushed, because Dmitry is the maintainer of ruby-mode, and most
>   importantly, nobody objected (much less I, who welcomed the enthusiasm
>   for using the new API).  So even though Emacs 26.1 is a month old, the
>   conservative stance is now to keep default.
>
> * On the practical front, I personally dislike defcustom and prefer
>   having flymake backends separate, so instead of having
>   ruby-flymake-auto checks the defcustom, I advise Petko to use a
>   directory-local variable in the project configuring
>   flymake-diagnostic-functions to either ruby-flymake-simple or
>   ruby-flymake-rubocop, i.e. some .dir-locals.el containing this
>
>      (...
>       (ruby-mode . (...
>                     (flymake-diagnostic-functions ruby-flymake-simple)
>                     ...))
>       ...)
>
>   Won't this suffice as a per-project (almost zero) configuration?
>
> João
>
>

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

[Dmitry Gutov]

On 6/16/18 6:32 PM, João Távora wrote:

>    There was little discussion on this before 26.1 because it was all
>    kinda rushed, because Dmitry is the maintainer of ruby-mode, and most
>    importantly, nobody objected (much less I, who welcomed the enthusiasm
>    for using the new API).  So even though Emacs 26.1 is a month old, the
>    conservative stance is now to keep default.

To be clear, I only did the most simple thing (and indeed, nobody 
objected). So anybody who doesn't like the behavior in 26.1, you're 
welcome to try out pretest versions. That's what they're for.

That said, I'm totally fine with adding a new value for 
ruby-flymake-use-rubocop-if-available (like `auto'), and make it the 
default. Because I personally have also been hit by it turning on in 
projects where it's not exactly needed. Like Ruby Stdlib, certain gems, 
etc. And older projects, yes.

I suggested the following already. Nobody responded to it so far:

"I suppose we can abort if no ruby-rubocop-config file is found."

Meaning, if there is no .rubocop.yml is any directory containing the 
current file, RuboCop is not used.

The main reasons I'm putting this off is avoiding calling 
locate-dominating-file twice, while keeping the simplicity of having two 
different diagnostic functions available for user use, is a bit tricky.

> * On the practical front, I personally dislike defcustom and prefer
>    having flymake backends separate, so instead of having
>    ruby-flymake-auto checks the defcustom, I advise Petko to use a
>    directory-local variable in the project configuring
>    flymake-diagnostic-functions to either ruby-flymake-simple or
>    ruby-flymake-rubocop, i.e. some .dir-locals.el containing this
> 
>       (...
>        (ruby-mode . (...
>                      (flymake-diagnostic-functions ruby-flymake-simple)
>                      ...))
>        ...)
>    
>    Won't this suffice as a per-project (almost zero) configuration?

That still leaves the question of a reasonable default. But if you ask 
me, removing the custom variable a making the "auto" behavior "always 
on" will also be good.

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

[Bozhidar Batsov]

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

I guess you can just look for .rubocop.yml in the root of the project.
That's not a precise way to infer if someone wants to use RuboCop, but it
should be good enough for most people (relatively few people have global
RuboCop configs).

I wonder if it won't be good to have a lint-mode only option as well -
generally `rubocop --lint` will show only things that are important to fix,
but it's much nicer than `ruby -w`. So, I'd still use rubocop for linting
if RuboCop is installed and use it for everything else only when the
project has some project config.

On Mon, 18 Jun 2018 at 17:02, Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 6/16/18 6:32 PM, João Távora wrote:
>
> >    There was little discussion on this before 26.1 because it was all
> >    kinda rushed, because Dmitry is the maintainer of ruby-mode, and most
> >    importantly, nobody objected (much less I, who welcomed the enthusiasm
> >    for using the new API).  So even though Emacs 26.1 is a month old, the
> >    conservative stance is now to keep default.
>
> To be clear, I only did the most simple thing (and indeed, nobody
> objected). So anybody who doesn't like the behavior in 26.1, you're
> welcome to try out pretest versions. That's what they're for.
>
> That said, I'm totally fine with adding a new value for
> ruby-flymake-use-rubocop-if-available (like `auto'), and make it the
> default. Because I personally have also been hit by it turning on in
> projects where it's not exactly needed. Like Ruby Stdlib, certain gems,
> etc. And older projects, yes.
>
> I suggested the following already. Nobody responded to it so far:
>
> "I suppose we can abort if no ruby-rubocop-config file is found."
>
> Meaning, if there is no .rubocop.yml is any directory containing the
> current file, RuboCop is not used.
>
> The main reasons I'm putting this off is avoiding calling
> locate-dominating-file twice, while keeping the simplicity of having two
> different diagnostic functions available for user use, is a bit tricky.
>
> > * On the practical front, I personally dislike defcustom and prefer
> >    having flymake backends separate, so instead of having
> >    ruby-flymake-auto checks the defcustom, I advise Petko to use a
> >    directory-local variable in the project configuring
> >    flymake-diagnostic-functions to either ruby-flymake-simple or
> >    ruby-flymake-rubocop, i.e. some .dir-locals.el containing this
> >
> >       (...
> >        (ruby-mode . (...
> >                      (flymake-diagnostic-functions ruby-flymake-simple)
> >                      ...))
> >        ...)
> >
> >    Won't this suffice as a per-project (almost zero) configuration?
>
> That still leaves the question of a reasonable default. But if you ask
> me, removing the custom variable a making the "auto" behavior "always
> on" will also be good.
>

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

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

[Dmitry Gutov]

Version: 27.1

On 18.06.2018 17:09, Bozhidar Batsov wrote:
> I guess you can just look for .rubocop.yml in the root of the project. 
> That's not a precise way to infer if someone wants to use RuboCop, but 
> it should be good enough for most people (relatively few people have 
> global RuboCop configs).
> 
> I wonder if it won't be good to have a lint-mode only option as well - 
> generally `rubocop --lint` will show only things that are important to 
> fix, but it's much nicer than `ruby -w`. So, I'd still use rubocop for 
> linting if RuboCop is installed and use it for everything else only when 
> the project has some project config.

Thanks, Bozhidar!

I've tried this approach, and it works well. So as of commit 
a361cc88a15e9c39f17145f9acd1ea4a8ca70461, we call rubocop with --lint if 
there's no .rubocop.yml in any parent directory of the current file.

It was an easy tweak.