* bug#31760: 26.1; ruby-mode enables flymake-rubocop by default if the rubocop executable exists @ 2018-06-08 14:55 Petko Bordjukov 2018-06-08 18:42 ` João Távora 0 siblings, 1 reply; 14+ messages in thread From: Petko Bordjukov @ 2018-06-08 14:55 UTC (permalink / raw) To: 31760 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)) ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#31760: 26.1; ruby-mode enables flymake-rubocop by default if the rubocop executable exists 2018-06-08 14:55 bug#31760: 26.1; ruby-mode enables flymake-rubocop by default if the rubocop executable exists Petko Bordjukov @ 2018-06-08 18:42 ` João Távora 2018-06-15 15:16 ` Dmitry Gutov 0 siblings, 1 reply; 14+ messages in thread From: João Távora @ 2018-06-08 18:42 UTC (permalink / raw) To: Petko Bordjukov; +Cc: 31760, dgutov 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 :-) ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#31760: 26.1; ruby-mode enables flymake-rubocop by default if the rubocop executable exists 2018-06-08 18:42 ` João Távora @ 2018-06-15 15:16 ` Dmitry Gutov 2018-06-15 17:54 ` Bozhidar Batsov 0 siblings, 1 reply; 14+ messages in thread From: Dmitry Gutov @ 2018-06-15 15:16 UTC (permalink / raw) To: João Távora, Petko Bordjukov; +Cc: 31760, Bozhidar Batsov 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? ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#31760: 26.1; ruby-mode enables flymake-rubocop by default if the rubocop executable exists 2018-06-15 15:16 ` Dmitry Gutov @ 2018-06-15 17:54 ` Bozhidar Batsov 2018-06-16 9:07 ` Petko Bordjukov 0 siblings, 1 reply; 14+ messages in thread From: Bozhidar Batsov @ 2018-06-15 17:54 UTC (permalink / raw) To: Dmitry Gutov; +Cc: Petko Bordjukov, João Távora, 31760 [-- 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 --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#31760: 26.1; ruby-mode enables flymake-rubocop by default if the rubocop executable exists 2018-06-15 17:54 ` Bozhidar Batsov @ 2018-06-16 9:07 ` Petko Bordjukov 2018-06-16 9:31 ` Bozhidar Batsov 2018-06-16 15:32 ` João Távora 0 siblings, 2 replies; 14+ messages in thread From: Petko Bordjukov @ 2018-06-16 9:07 UTC (permalink / raw) To: Bozhidar Batsov; +Cc: João Távora, 31760, Dmitry Gutov > 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? ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#31760: 26.1; ruby-mode enables flymake-rubocop by default if the rubocop executable exists 2018-06-16 9:07 ` Petko Bordjukov @ 2018-06-16 9:31 ` Bozhidar Batsov 2018-06-16 9:36 ` Bozhidar Batsov 2018-06-16 15:32 ` João Távora 1 sibling, 1 reply; 14+ messages in thread From: Bozhidar Batsov @ 2018-06-16 9:31 UTC (permalink / raw) To: Petko Bordjukov; +Cc: João Távora, 31760, Dmitry Gutov [-- 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 --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#31760: 26.1; ruby-mode enables flymake-rubocop by default if the rubocop executable exists 2018-06-16 9:31 ` Bozhidar Batsov @ 2018-06-16 9:36 ` Bozhidar Batsov 2018-06-16 19:47 ` Petko Bordjukov 0 siblings, 1 reply; 14+ messages in thread From: Bozhidar Batsov @ 2018-06-16 9:36 UTC (permalink / raw) To: Petko Bordjukov; +Cc: João Távora, 31760, Dmitry Gutov [-- 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 --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#31760: 26.1; ruby-mode enables flymake-rubocop by default if the rubocop executable exists 2018-06-16 9:36 ` Bozhidar Batsov @ 2018-06-16 19:47 ` Petko Bordjukov 2018-06-16 19:55 ` Bozhidar Batsov 0 siblings, 1 reply; 14+ messages in thread From: Petko Bordjukov @ 2018-06-16 19:47 UTC (permalink / raw) To: Bozhidar Batsov; +Cc: João Távora, 31760, Dmitry Gutov > 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? ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#31760: 26.1; ruby-mode enables flymake-rubocop by default if the rubocop executable exists 2018-06-16 19:47 ` Petko Bordjukov @ 2018-06-16 19:55 ` Bozhidar Batsov 0 siblings, 0 replies; 14+ messages in thread From: Bozhidar Batsov @ 2018-06-16 19:55 UTC (permalink / raw) To: Petko Bordjukov; +Cc: João Távora, 31760, Dmitry Gutov [-- 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 --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#31760: 26.1; ruby-mode enables flymake-rubocop by default if the rubocop executable exists 2018-06-16 9:07 ` Petko Bordjukov 2018-06-16 9:31 ` Bozhidar Batsov @ 2018-06-16 15:32 ` João Távora 2018-06-16 19:54 ` Petko Bordjukov 2018-06-18 14:02 ` Dmitry Gutov 1 sibling, 2 replies; 14+ messages in thread From: João Távora @ 2018-06-16 15:32 UTC (permalink / raw) To: Petko Bordjukov; +Cc: Bozhidar Batsov, 31760, Dmitry Gutov 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#31760: 26.1; ruby-mode enables flymake-rubocop by default if the rubocop executable exists 2018-06-16 15:32 ` João Távora @ 2018-06-16 19:54 ` Petko Bordjukov 2018-06-18 14:02 ` Dmitry Gutov 1 sibling, 0 replies; 14+ messages in thread From: Petko Bordjukov @ 2018-06-16 19:54 UTC (permalink / raw) To: João Távora; +Cc: Bozhidar Batsov, 31760, Dmitry Gutov > 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 > > ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#31760: 26.1; ruby-mode enables flymake-rubocop by default if the rubocop executable exists 2018-06-16 15:32 ` João Távora 2018-06-16 19:54 ` Petko Bordjukov @ 2018-06-18 14:02 ` Dmitry Gutov 2018-06-18 14:09 ` Bozhidar Batsov 1 sibling, 1 reply; 14+ messages in thread From: Dmitry Gutov @ 2018-06-18 14:02 UTC (permalink / raw) To: João Távora, Petko Bordjukov; +Cc: Bozhidar Batsov, 31760 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#31760: 26.1; ruby-mode enables flymake-rubocop by default if the rubocop executable exists 2018-06-18 14:02 ` Dmitry Gutov @ 2018-06-18 14:09 ` Bozhidar Batsov 2018-12-25 15:36 ` Dmitry Gutov 0 siblings, 1 reply; 14+ messages in thread From: Bozhidar Batsov @ 2018-06-18 14:09 UTC (permalink / raw) To: Dmitry Gutov; +Cc: Petko Bordjukov, João Távora, 31760 [-- 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 --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#31760: 26.1; ruby-mode enables flymake-rubocop by default if the rubocop executable exists 2018-06-18 14:09 ` Bozhidar Batsov @ 2018-12-25 15:36 ` Dmitry Gutov 0 siblings, 0 replies; 14+ messages in thread From: Dmitry Gutov @ 2018-12-25 15:36 UTC (permalink / raw) To: Bozhidar Batsov; +Cc: Petko Bordjukov, João Távora, 31760-done 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2018-12-25 15:36 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-06-08 14:55 bug#31760: 26.1; ruby-mode enables flymake-rubocop by default if the rubocop executable exists Petko Bordjukov 2018-06-08 18:42 ` João Távora 2018-06-15 15:16 ` Dmitry Gutov 2018-06-15 17:54 ` Bozhidar Batsov 2018-06-16 9:07 ` Petko Bordjukov 2018-06-16 9:31 ` Bozhidar Batsov 2018-06-16 9:36 ` Bozhidar Batsov 2018-06-16 19:47 ` Petko Bordjukov 2018-06-16 19:55 ` Bozhidar Batsov 2018-06-16 15:32 ` João Távora 2018-06-16 19:54 ` Petko Bordjukov 2018-06-18 14:02 ` Dmitry Gutov 2018-06-18 14:09 ` Bozhidar Batsov 2018-12-25 15:36 ` Dmitry Gutov
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.