From unknown Sun Jun 22 17:12:52 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#31760 <31760@debbugs.gnu.org> To: bug#31760 <31760@debbugs.gnu.org> Subject: Status: 26.1; ruby-mode enables flymake-rubocop by default if the rubocop executable exists Reply-To: bug#31760 <31760@debbugs.gnu.org> Date: Mon, 23 Jun 2025 00:12:52 +0000 retitle 31760 26.1; ruby-mode enables flymake-rubocop by default if the rub= ocop executable exists reassign 31760 emacs submitter 31760 Petko Bordjukov severity 31760 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 08 14:32:52 2018 Received: (at submit) by debbugs.gnu.org; 8 Jun 2018 18:32:52 +0000 Received: from localhost ([127.0.0.1]:39949 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fRMBw-0005eL-3j for submit@debbugs.gnu.org; Fri, 08 Jun 2018 14:32:52 -0400 Received: from eggs.gnu.org ([208.118.235.92]:41895) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fRIo0-00071i-Hf for submit@debbugs.gnu.org; Fri, 08 Jun 2018 10:55:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fRInt-0005yp-J9 for submit@debbugs.gnu.org; Fri, 08 Jun 2018 10:55:51 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:46765) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fRInt-0005ya-FS for submit@debbugs.gnu.org; Fri, 08 Jun 2018 10:55:49 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:32852) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fRInr-0008C0-EN for bug-gnu-emacs@gnu.org; Fri, 08 Jun 2018 10:55:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fRInm-0005vz-Gt for bug-gnu-emacs@gnu.org; Fri, 08 Jun 2018 10:55:47 -0400 Received: from mail-wm0-x235.google.com ([2a00:1450:400c:c09::235]:38812) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fRInm-0005ux-6J for bug-gnu-emacs@gnu.org; Fri, 08 Jun 2018 10:55:42 -0400 Received: by mail-wm0-x235.google.com with SMTP id 69-v6so4288396wmf.3 for ; Fri, 08 Jun 2018 07:55:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:message-id:from:to:subject:user-agent:mime-version; bh=z9EAwWP3/XefT7QeS9P9BUhdtfTqafTjN53BXqUWHis=; b=nl82I+qAcL3+MGoqfcUnCK2xZ2iXJU2qiXjpCbJNV+96nzEuOVTu+3nnBFTFXsmPv/ 9xR6uPyVPcdup3IhsbgIm4X571EbDoAg/sVGO4r4B3CUP1hMnhwloU1EQUFlFHm3ltZV gFXS5drnBP2KZbets5g5kbXg8JZL4ms306Mr+A+Jpq9izvRLo68C5LOAHLRpkCK1dxLO x1djh1e6WKOd9mPdXe446CLDgrOJNmtTJGmL1j/5bxIi2sPnG20IslRJi7IBmU0dBYy3 lmQbUmNVhfEB55glvJdVZo8AAJlFi1rVj4H2Xq8cVXAp8D6JilS9nKpfGmN+vT20cTuS t7xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:message-id:from:to:subject:user-agent :mime-version; bh=z9EAwWP3/XefT7QeS9P9BUhdtfTqafTjN53BXqUWHis=; b=HlVoJ9yJgvQcdI966pTed+B6y9BvGAzn0tErGmWfGds4H3gXz2HvZ1sKyJqCybH9/T IRM9Yinkq5yH1IEPD/QGFRxc/W11o+UlTOrqxQcJw3GJ2BgY+CYXMJSBlKKiUeUVNjrO Ido35ZBad2PpAIhyaOcQJgIOjMDzDRsdS+r5vOA8D7DPlVTjEMN3AgX+gc9VVz7bM9fl PtOXgfYpNyyZNyKqIbJXXIBA2DWMXsFc/qDE1k1bT+01beJW5Ss3QoVPJtVnD2Zj+UfQ bdF8oWV8GWHJ/8TOdWz4t9j3uu3ouA+jk3PfLfvAn5NaYNCiiR5/30gnQC7BRj2GB1jH RYxw== X-Gm-Message-State: APt69E3s58nvQweE2n+uhV1QMwCQgZM7RMIh7VtUrpNg23ocNzrv68YN VRc8RC9qR0QmZlXgQVvqLJ9wj02V X-Google-Smtp-Source: ADUXVKJp8fJrcCvidKJIh2zjJNBUotmx6fi+BN7mWvCoMK568rH/j5AE6j8RuHMojEwxIRG/nIjErQ== X-Received: by 2002:a1c:bf43:: with SMTP id p64-v6mr1712123wmf.71.1528469740350; Fri, 08 Jun 2018 07:55:40 -0700 (PDT) Received: from clarity.gmail.com (46-10-52-246.ip.btc-net.bg. [46.10.52.246]) by smtp.gmail.com with ESMTPSA id c11-v6sm43973885wrm.65.2018.06.08.07.55.39 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 08 Jun 2018 07:55:39 -0700 (PDT) Date: Fri, 08 Jun 2018 17:55:38 +0300 Message-ID: <87k1r972fp.wl-bordjukov@gmail.com> From: Petko Bordjukov To: bug-gnu-emacs@gnu.org Subject: 26.1; ruby-mode enables flymake-rubocop by default if the rubocop executable exists User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/26 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Fri, 08 Jun 2018 14:32:50 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) 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)) From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 08 14:42:42 2018 Received: (at 31760) by debbugs.gnu.org; 8 Jun 2018 18:42:42 +0000 Received: from localhost ([127.0.0.1]:39967 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fRMLR-0005tg-PW for submit@debbugs.gnu.org; Fri, 08 Jun 2018 14:42:41 -0400 Received: from mail-wm0-f41.google.com ([74.125.82.41]:36464) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fRMLQ-0005tU-Bk for 31760@debbugs.gnu.org; Fri, 08 Jun 2018 14:42:40 -0400 Received: by mail-wm0-f41.google.com with SMTP id v131-v6so5402509wma.1 for <31760@debbugs.gnu.org>; Fri, 08 Jun 2018 11:42:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version; bh=968MDVPrsdr1egotu/bBRhhUIKioBfo5pAsUk8A0UE8=; b=kzJiiOWLDfe7moS9H/rQzbPXOsDeRAj7CHeoRCpHLePpc4iFPlR5mmtXtlkW1kO0JN mBLdBJsXV3tv4HJD66ZZkB5RcCQa6ewEVBOYvWaZyEHvVXbERZpTFtNBb/1OXwVQ/nTj csUHPD0jbFqsJSjDxNU7Nc0wPCpSKzqYGboWmDJ+moqUPTOqgmK4TSpJWWp965Ru1sdv G50EpXrUk1U9xp3BBE2g2u7UAfClR6RL8U7TJv+Ukbs6ki5kE1QHKpRjuGK9nmAzzFTN wlSFKVdbJG7oQ495jqCKvjcBDWKDVYUUBeg2BAZ+mCCjTk9V3it2DbTBA2LV8gJl6RM5 rXOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references :user-agent:date:message-id:mime-version; bh=968MDVPrsdr1egotu/bBRhhUIKioBfo5pAsUk8A0UE8=; b=TSL3MvQauJRCI8T38tyrbBjN6AdTaGH/TdWbgCzw0FgJhRWOoof2t+8uPQYznErAZ+ 9l1D+jFC+KbFbaUIuv8WmQE8xIE2QbiYmXm+XTO6VYj8D8eMhJxw2lPXuPjDcpmjT/Xt Tq9vCQjhPiCmn+RtKjY/8204gO1Te55NQ+H3tam8whdEk/5tOE+8SBYSFsV/7Ebfr2ho JraoEjdu7pF4mf29wQWV8+BZaCF6OUWgQnMpkIfwO2FzMM20zoiIvztnNcppDwolUg5W DlRpGnTFR6mknKeUj08Tuj/NdhXisNNXCLdWdh5GHOfDlbpk6X1PRgOxBEjeG/M9uPw3 /m1A== X-Gm-Message-State: APt69E39c7WmLKsZy1U1ewslRGwA9Tjt5p5+RElROs5scUkagwcfqJpd ye9IWzkvd1zifVitn7+B5j8= X-Google-Smtp-Source: ADUXVKJvcmt2FGRvPCflw49fv+11N7ZSc1O3+wJncvIbYE7cyITd+6mzXNwW8vm4grn+o/8Egwg4ZQ== X-Received: by 2002:a1c:9a51:: with SMTP id c78-v6mr2218043wme.118.1528483354546; Fri, 08 Jun 2018 11:42:34 -0700 (PDT) Received: from lolita.yourcompany.com (188.139.62.94.rev.vodafone.pt. [94.62.139.188]) by smtp.gmail.com with ESMTPSA id q17-v6sm26174528wrs.5.2018.06.08.11.42.33 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 08 Jun 2018 11:42:33 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= To: Petko Bordjukov Subject: Re: bug#31760: 26.1; ruby-mode enables flymake-rubocop by default if the rubocop executable exists In-Reply-To: <87k1r972fp.wl-bordjukov@gmail.com> (Petko Bordjukov's message of "Fri, 08 Jun 2018 17:55:38 +0300") References: <87k1r972fp.wl-bordjukov@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Date: Fri, 08 Jun 2018 19:42:21 +0100 Message-ID: <87po11i0he.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 31760 Cc: 31760@debbugs.gnu.org, dgutov@yandex.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.9 (/) Petko Bordjukov 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 :-) From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 15 11:16:10 2018 Received: (at 31760) by debbugs.gnu.org; 15 Jun 2018 15:16:10 +0000 Received: from localhost ([127.0.0.1]:50546 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fTqSQ-0001Lw-Gz for submit@debbugs.gnu.org; Fri, 15 Jun 2018 11:16:10 -0400 Received: from mail-wr0-f171.google.com ([209.85.128.171]:41648) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fTqSP-0001Ll-Tj for 31760@debbugs.gnu.org; Fri, 15 Jun 2018 11:16:10 -0400 Received: by mail-wr0-f171.google.com with SMTP id h10-v6so10271370wrq.8 for <31760@debbugs.gnu.org>; Fri, 15 Jun 2018 08:16:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=bYyHV3LvikBpJMr9YyOvYlLqyDev1HdJV5RmjriJ7jY=; b=WkgEiNFHqsKafoSMfKUjM9Ko1qkGoIsQKXDkmGlpOFdpHGyWFWoySkAJelK26SZQmz 8rFa2DCwMekL1H3LZ6o6b9+23TFP1HiwIso4Jp1phFCl4OH04WULBQ2ikFXD2hm5QDrx wts7pZTG7xgwEw3JPgY3YRgdmxt6CJg8B2FOKdtxDTD8ADOCXrvWKMkZlMh5azZLSBoP 54FLSlShl0p9gOKRjB62EziGUnVZ75TYHQ6qSFliCdailK9NNl6qI6YED074FEBxxNVQ 6eTh/qQJfDRggBOjhHhOX/Ezy4lwTCEufJ7BRqCf8qUoFCe4utO4xtBDJwtv+BnmciZ2 UJMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=bYyHV3LvikBpJMr9YyOvYlLqyDev1HdJV5RmjriJ7jY=; b=kHB/hHNIzg6x1hrz9nQUyBFsz556XgaEmrD0rBGjrlk3DT6fDqEuC8/JmNvopZ0Vib /zFt1bctX2+J+vacL8KuTkfS2NmztHOrDeM3We+36Q2PTYsdCkmTMTENY3Jpt0qoTDS/ dNrdQ3wbf7OiRVj4+T3C+wPi/oVwzRD7qEX8bq6ILhjGVyEBPrXhFgPx1QHJgU+KHpLB 15sLPoLwnK2XUS2mLZMS7+0pBOVVy1xpQWeURqmAfqXRgYK4ag09xAiJgkIsCYlRtbDL sYsfnbv8UK2o93isRtY9I7ZVU+EVOdmumVljSBl7yef+N7Pj3AV5GvCkAQ22pS9Rxh0C R5QQ== X-Gm-Message-State: APt69E1NlfivkiRFUVv3PTPVmET37O+Icsr3/xNTu/c+iSeFDILfcqpO c79ow67/e6zN382RmgEw9CU= X-Google-Smtp-Source: ADUXVKIju1NjLKwfg16P3ZWiOB0R+u/XoLYNoBqljv4C4SU7j899Row0CJNc7HLDmuyNzmMjexZ0nw== X-Received: by 2002:adf:f090:: with SMTP id n16-v6mr2169307wro.49.1529075763986; Fri, 15 Jun 2018 08:16:03 -0700 (PDT) Received: from [192.168.0.200] ([212.50.99.193]) by smtp.googlemail.com with ESMTPSA id f18-v6sm11474529wro.1.2018.06.15.08.16.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Jun 2018 08:16:02 -0700 (PDT) Subject: Re: bug#31760: 26.1; ruby-mode enables flymake-rubocop by default if the rubocop executable exists To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= , Petko Bordjukov References: <87k1r972fp.wl-bordjukov@gmail.com> <87po11i0he.fsf@gmail.com> From: Dmitry Gutov Message-ID: <83d8f202-8842-56fe-0350-5f2fa9a01d67@yandex.ru> Date: Fri, 15 Jun 2018 18:16:00 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <87po11i0he.fsf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 31760 Cc: Bozhidar Batsov , 31760@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 6/8/18 9:42 PM, João Távora wrote: > Petko Bordjukov 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? From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 15 13:54:48 2018 Received: (at 31760) by debbugs.gnu.org; 15 Jun 2018 17:54:48 +0000 Received: from localhost ([127.0.0.1]:50639 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fTsvu-0006ws-2k for submit@debbugs.gnu.org; Fri, 15 Jun 2018 13:54:48 -0400 Received: from mail-qt0-f179.google.com ([209.85.216.179]:46525) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fTsvs-0006wg-RP for 31760@debbugs.gnu.org; Fri, 15 Jun 2018 13:54:45 -0400 Received: by mail-qt0-f179.google.com with SMTP id h5-v6so9775665qtm.13 for <31760@debbugs.gnu.org>; Fri, 15 Jun 2018 10:54:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=batsov-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=usl1iAft3lkCEv/h/EI8ANWLkG4QvqG0qVFOp2IRXys=; b=OoEgdjFBfsQISxbIyNLaAyi8wsgDL4e15Lo+DTepwHrlBUU2V+sNNlRH+NktFvKYWQ Gs3sOolA3I91Lp5Lgu0GbEdAGAhuEM/ej2UfNKp6UEekHRcOb2IO2bSnxRBqVBkI9A7H yj/0ORv2gZFdFfyJ9AxfLHjhtPQM/JVLkcY7diy/DLAZM2XhQ7pc78v7dGSffH85qY9l Zzt3aiOcD5WYmgSBsLSDF4QzZmT+3Iyo9mrfWl3ltZ79YKa+exh4RiFwGBd4wfI6JYVC Z7zUeLxIhWPcZCHTzfZUMAMWpUIL14vG/K9of/5ao2wfRSWXDZO198ZblNUMcNDMidcf 4Iwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=usl1iAft3lkCEv/h/EI8ANWLkG4QvqG0qVFOp2IRXys=; b=Dx2rxR5G7GNexQ5mdzLbQ2S9njWW6tHErQTOoPQFGJRZawX8slZ/Rnn5SW81sEPieK tFqPwS6hH920Jowr9CuDXBseT8tHmKPIfr6oPMXiPiMkwacXY5RnwsZk8/HP/l+aSi4q XivM1HLM7FOiGoIpGsuIsSstL3tXJ20ErNSspNC6HRk8Gfi8CY0VaE27JBxazKjP2VIa kSZ7zl1bEtofaqJnT4tExdXUW8XTJ8PgqzHryESCfqrFadfOAj3iO7W9Fjk7TJAeXFbV OQwsKPJQ6VdQP43cWOQIlDM3ptIcn15zRMxRjDr76ZyuF5xzCreFcgLRgx7Z/xQu4Ieq yM0Q== X-Gm-Message-State: APt69E3W0of3xMse+5v+97kvlKkOky54Nb+CK7X+3zRCZKRpVCHnE+Vq 0WaRFD1HOhAYAxiqj2bxgDmRDtbECKLgtu/UZxg= X-Google-Smtp-Source: ADUXVKLJ/V7wbKGeQGPc6ZqgU8eAQ/nJGEAWUqaMhRpEh2LfHtwO3kAr4GYUp1BL5brxqOjZh9mAsTjubhBKlP8Zo1w= X-Received: by 2002:ac8:1bee:: with SMTP id m43-v6mr2502576qtk.339.1529085279201; Fri, 15 Jun 2018 10:54:39 -0700 (PDT) MIME-Version: 1.0 References: <87k1r972fp.wl-bordjukov@gmail.com> <87po11i0he.fsf@gmail.com> <83d8f202-8842-56fe-0350-5f2fa9a01d67@yandex.ru> In-Reply-To: <83d8f202-8842-56fe-0350-5f2fa9a01d67@yandex.ru> From: Bozhidar Batsov Date: Fri, 15 Jun 2018 19:54:27 +0200 Message-ID: Subject: Re: bug#31760: 26.1; ruby-mode enables flymake-rubocop by default if the rubocop executable exists To: Dmitry Gutov Content-Type: multipart/alternative; boundary="000000000000e5ed91056eb1e8b6" X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 31760 Cc: Petko Bordjukov , =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= , 31760@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) --000000000000e5ed91056eb1e8b6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 wrote: > On 6/8/18 9:42 PM, Jo=C3=A3o T=C3=A1vora wrote: > > Petko Bordjukov writes: > > > >> Emacs 26.1 enables flymake-rubocop by default if the rubocop executabl= e > >> 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 b= y > >> 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? > --000000000000e5ed91056eb1e8b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 def= custom mentioned.

>=C2=A0Sin= ce most if not all of the warnings that
>> Rubocop ge= nerates are not raised by Ruby I consider them not adopted by
>> the Ruby community by default.

You know this thing is configu= rable, right? ;-) The vast majority of checks are actually pretty much comm= unity standard - Ruby produces only a minimal amount of lint warnings, Rubo= Cop has extended linting but also a lot of code style checking functionalit= y.=C2=A0

I don't really want us to check for RuboCop config files (th= ose are hierarchical and won't necessarily be in the root of your curre= nt project anyways) - I think the current check + config is sufficient.=C2= =A0

On Fr= i, 15 Jun 2018 at 17:16, Dmitry Gutov <dgutov@yandex.ru> wrote:
= On 6/8/18 9:42 PM, Jo=C3=A3o T=C3=A1vora wrote:
> Petko Bordjukov <bordjukov@gmail.com> writes:
>
>> Emacs 26.1 enables flymake-rubocop by default if the rubocop execu= table
>> is present in the system. Since most if not all of the warnings th= at
>> Rubocop generates are not raised by Ruby I consider them not adopt= ed by
>> the Ruby community by default. Based on that, I propose that eithe= r
>> using Rubocop by default is turned off, or at least a more intelig= ent
>> 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?
--000000000000e5ed91056eb1e8b6-- From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 16 05:07:47 2018 Received: (at 31760) by debbugs.gnu.org; 16 Jun 2018 09:07:47 +0000 Received: from localhost ([127.0.0.1]:50983 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fU7BT-0006VZ-4V for submit@debbugs.gnu.org; Sat, 16 Jun 2018 05:07:47 -0400 Received: from mail-qk0-f172.google.com ([209.85.220.172]:36285) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fU7BP-0006VK-A9 for 31760@debbugs.gnu.org; Sat, 16 Jun 2018 05:07:43 -0400 Received: by mail-qk0-f172.google.com with SMTP id a195-v6so6978052qkg.3 for <31760@debbugs.gnu.org>; Sat, 16 Jun 2018 02:07:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=OFPg4WLIkINeoYpICzxUyIjVEW4VlIaQJ8cPLwP/O48=; b=jlItazkfKrnOird7VKtKJ5VNGH/r/gWi3nRytQz4/J3pPxjE36vzWg6AOfu9o5/YXo 5uT9/9YbZpXmHAeg2raRibyN7iGfsx948M0pHwjBGx0rC2JdWiDX5ubkhpBBQ/a2buZD 4WpKQP+/HkeN4t56LRwVjUlYz+sN8EP+UqtadMsSGSaNYB9umR8+qPtkxI4V0K5oPeWY 1GlwkGnoEt9RnushKnbCXXlPF03/qj6b5YcxYqBLNtu3v3aA54OK7JmzMTb8fMmawGbZ ymL4YvuRz24xNcf5AoaRNKJMEBPXv0mko30H0oGvd80Xqyk697lRRRhwe8CQ5pDRHB+h lILw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=OFPg4WLIkINeoYpICzxUyIjVEW4VlIaQJ8cPLwP/O48=; b=FOWICvUI6xL0sfRw/F3owg3uUBDGnx93JFbsKkS3FNn5sbemXYsFmBhv5BxIfZBWgs yvbG7fp7yqisHBIhUtqrBCe0b0XDc+++s+zCY9vLLhI810hhRTwNdP62Yd7s+8Phnbd9 YQp8HuZDoPi+jM84+vKj4onARGnMXvR9aETvSEsJv8mD5ii5Qk6uhIw+HdI/g1K3f2R9 Bvw5g8+hvcRKEV9GJxlui2u4QpelRjzuevJKVOLCT5Rprcf2jJDOfS0qn4JsHz9fZoLI K0xP4b7Tb6YayaB/eWPN0Z7+gtIeBOGy4Ad/SI821+12uzOaHnbVKy+eMaCEhmKbkUDr yizA== X-Gm-Message-State: APt69E33tRbd8dkTei7uhgEpPwxGAW0P2pIwb5dneWJjmj6CZP7MIOe/ 17bi6BMLson4GSfReho5DG0upPck37BvpVyYsng= X-Google-Smtp-Source: ADUXVKLTWxBnfi04CiRsGA6YRybAmyWSDuH02tnBytvlHU63yBWE2+5/C3H5F33VHk3CsIRCiTHjjbh1X/Aj7AxrcYE= X-Received: by 2002:a37:255:: with SMTP id 82-v6mr4275626qkc.425.1529140057791; Sat, 16 Jun 2018 02:07:37 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:aed:26a4:0:0:0:0:0 with HTTP; Sat, 16 Jun 2018 02:07:36 -0700 (PDT) In-Reply-To: References: <87k1r972fp.wl-bordjukov@gmail.com> <87po11i0he.fsf@gmail.com> <83d8f202-8842-56fe-0350-5f2fa9a01d67@yandex.ru> From: Petko Bordjukov Date: Sat, 16 Jun 2018 12:07:36 +0300 Message-ID: Subject: Re: bug#31760: 26.1; ruby-mode enables flymake-rubocop by default if the rubocop executable exists To: Bozhidar Batsov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 31760 Cc: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= , 31760@debbugs.gnu.org, Dmitry Gutov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > So... First of all, there is the variable ruby-flymake-use-rubocop-if-ava= ilable, 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 wrot= e: > Why would have RuboCop installed and not what to use it? > > I think the check is perfectly fine in its current state, especially give= n > 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 chec= ks > are actually pretty much community standard - Ruby produces only a minima= l > amount of lint warnings, RuboCop has extended linting but also a lot of c= ode > 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 wrote: >> >> On 6/8/18 9:42 PM, Jo=C3=A3o T=C3=A1vora wrote: >> > Petko Bordjukov writes: >> > >> >> Emacs 26.1 enables flymake-rubocop by default if the rubocop executab= le >> >> 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? From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 16 05:31:23 2018 Received: (at 31760) by debbugs.gnu.org; 16 Jun 2018 09:31:23 +0000 Received: from localhost ([127.0.0.1]:50988 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fU7YH-00072L-7Y for submit@debbugs.gnu.org; Sat, 16 Jun 2018 05:31:21 -0400 Received: from mail-qk0-f171.google.com ([209.85.220.171]:36779) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fU7YE-000728-Rd for 31760@debbugs.gnu.org; Sat, 16 Jun 2018 05:31:19 -0400 Received: by mail-qk0-f171.google.com with SMTP id a195-v6so6992269qkg.3 for <31760@debbugs.gnu.org>; Sat, 16 Jun 2018 02:31:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=batsov-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nrX5LsBdHuLKAI+DIVOBRsJdy9LM1MDno4mQaKpalbU=; b=0pbiE3Jjj3rlShkpPx87x6ZYRbTG7CQyteRDofL5h5+ZWEa3aBzfP4r/Key85MwWeA h2R7/2nxcQo8KC3SQg5NfE8DItRah8a9e1tysJ7fV55x3AjPTyrsus0EswJBTEXYGMY1 MEI/LwBMD3lb8vgWgGynAAVvfwMlxZoHc4i2r69jNhj+rSeihtkWCAWL+An/za2u05iV XEzzZMLUyvP2QGlHN0KgBeWGA9gxDe0/s145kbKXR94X/A+NkoKDZbN4k0zTRFfhdcYp Zlq4k9ePSkY1rnHiNXLut/mycdUZNHmp+sKBa2fZlWSjRXq2AffvlDqFMBRZMwr8/5PV y7aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nrX5LsBdHuLKAI+DIVOBRsJdy9LM1MDno4mQaKpalbU=; b=jRfHjBYH7GMs6PhA75ihpGtM0PCP1B/243mY6vWR1ku6U50vJOT5cyU5EsrOMs+B2e 6tpZIib0jyuvbgGUpBxjnfeWAOAG7Cm4OwQVYvS85tyRtok4X0jjPZmzlPUCDR6L/UNJ VGSXs40pQ3O1r40Y80xUdv1VuaDAVCo3IHHPfr7wjueeuV4Qg49buZUhmwk0+U4LYkbG 0b+VLCDH0PaPLjekQ/spNuJKbw8UiS7VCHAnEk8rvJXwoPeUe8d0cyyXDlGMvuNFfu8r sGqqvaXA5kEXZaDGd/5ygeEDEh+/NyJRJvQWWhSss8gVALvrUetBrEYGFClkgy+xDrrT uMhg== X-Gm-Message-State: APt69E3EFzdtQBmoYBkNiJsNdMkVA4bpNyPogFMfgcpba1stnwALx+Fk yyO05SwAr66GLU2afg/RNPY0JYdr4s4AmlPl8TI= X-Google-Smtp-Source: ADUXVKLwx38MpmbbQJ97icEJw+TSxBISuUOzjJBOvQk9OiRkpdf7dLBDmIv+lu3PJm6yD00bvblrLOx1zehX/EOXQQc= X-Received: by 2002:a37:646:: with SMTP id 67-v6mr4014970qkg.35.1529141473304; Sat, 16 Jun 2018 02:31:13 -0700 (PDT) MIME-Version: 1.0 References: <87k1r972fp.wl-bordjukov@gmail.com> <87po11i0he.fsf@gmail.com> <83d8f202-8842-56fe-0350-5f2fa9a01d67@yandex.ru> In-Reply-To: From: Bozhidar Batsov Date: Sat, 16 Jun 2018 12:31:02 +0300 Message-ID: Subject: Re: bug#31760: 26.1; ruby-mode enables flymake-rubocop by default if the rubocop executable exists To: Petko Bordjukov Content-Type: multipart/alternative; boundary="00000000000053e82e056ebefec2" X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 31760 Cc: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= , 31760@debbugs.gnu.org, Dmitry Gutov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) --00000000000053e82e056ebefec2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, 16 Jun 2018 at 12:07, Petko Bordjukov wrote: > > So... First of all, there is the variable > ruby-flymake-use-rubocop-if-available, to satisfy the individual preferen= ce > 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 > 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 proje= ct > > anyways) - I think the current check + config is sufficient. > > > > On Fri, 15 Jun 2018 at 17:16, Dmitry Gutov wrote: > >> > >> On 6/8/18 9:42 PM, Jo=C3=A3o T=C3=A1vora wrote: > >> > Petko Bordjukov 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 tha= t > >> >> Rubocop generates are not raised by Ruby I consider them not adopte= d > 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 intelige= nt > >> >> 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 wo= rk > >> 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? > --00000000000053e82e056ebefec2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


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-rub= ocop-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 experi= ence, so your comment is subjective by default. :-)=C2=A0

> 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 p= roject 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 (especia= lly in a professional setting) in recent years
and looking at its= rising popularity I guess the usage will grow.=C2=A0=C2=A0

> The vast majority of checks are actually pretty much community standar= d - Ruby produces only a minimal amount of lint warnings, RuboCop has exten= ded 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 upstrea= m, as this would tie the language development cycle to the tooling developm= ent cycle. Linters are supposed to be downstream projects that can evolve i= ndependently (it's the same with all Java linters, Python linters, ES l= inters, etc).
=C2=A0
To add t= o 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 care= fully checked that layout config is Emacs compatible.=C2=A0
=C2= =A0

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.

<= div>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 b= y most people, as flycheck is super popular these days). You should really = understand that we can't be making decisions based on the

<= div>=C2=A0

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 g= iven
> the fact that you can simply disable RuboCop with the defcustom mentio= ned.
>
>> Since most if not all of the warnings that
>>> Rubocop generates are not raised by Ruby I consider them not a= dopted by
>>> the Ruby community by default.
>
> You know this thing is configurable, right? ;-) The vast majority of c= hecks
> are actually pretty much community standard - Ruby produces only a min= imal
> amount of lint warnings, RuboCop has extended linting but also a lot o= f code
> style checking functionality.
>
> I don't really want us to check for RuboCop config files (those ar= e
> 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=C3=A3o T=C3=A1vora wrote:
>> > Petko Bordjukov <bordjukov@gmail.com> writes:
>> >
>> >> Emacs 26.1 enables flymake-rubocop by default if the rubo= cop executable
>> >> is present in the system. Since most if not all of the wa= rnings that
>> >> Rubocop generates are not raised by Ruby I consider them = not adopted by
>> >> the Ruby community by default. Based on that, I propose t= hat either
>> >> using Rubocop by default is turned off, or at least a mor= e 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 ca= n
>> abort if no ruby-rubocop-config file is found. That would certainl= y 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?
--00000000000053e82e056ebefec2-- From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 16 05:37:09 2018 Received: (at 31760) by debbugs.gnu.org; 16 Jun 2018 09:37:10 +0000 Received: from localhost ([127.0.0.1]:50996 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fU7dt-0007Cl-A0 for submit@debbugs.gnu.org; Sat, 16 Jun 2018 05:37:09 -0400 Received: from mail-qt0-f178.google.com ([209.85.216.178]:43535) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fU7dq-0007CE-D7 for 31760@debbugs.gnu.org; Sat, 16 Jun 2018 05:37:07 -0400 Received: by mail-qt0-f178.google.com with SMTP id y89-v6so11239371qtd.10 for <31760@debbugs.gnu.org>; Sat, 16 Jun 2018 02:37:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=batsov-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lPOE+tVivY9bMtS82ERkHy+QjZRVKv7/ur+F3aEUsBM=; b=RKRzEqR54hgFlx84TFm0JDhavwuV0m4/nqzRQuy7vSkDCO0Rgsw4oXep0a6Titn+z6 L8dq/lxfZ5oHF7f7VXASmeWuSp766tHJSx4ZulwSrJR+63Q19aVVEFRdixGrsftyTKMP feNC8Fqego0ZHckGPdzUYU8fbmj+4PJzfpzsgPAlNc9wl+s/49rHqYRHDfQcVbCKan+R PLBoTsRatspc2JZoGU1tyYGqfzEhFJpB8+GkyPxmIYOvkMwK+Ao7OP9KzT6g55saqpYw hCs/FVRvXhOUsErkSnBCYOj69UvHDcZnt6IIyHLLwx6e4VYyFMiiYEpTQZko4Z/2x/Vr PJvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lPOE+tVivY9bMtS82ERkHy+QjZRVKv7/ur+F3aEUsBM=; b=poNMIxLqkbzxdPiu8ZBWDjJPbqPmtgNdetSl7mtIzefmRvtHKODRwiZkVcZaVhbGsJ gzVQuRxbUsJvvNqJY449fPv4QXkF7fPK9UFYvHjFGFQK7f7BQYo55yL/ZeolVvHAllhm rp4rGNtVWpPJse2JvmhnA6E6/lvVvzJRfytKQdYYqdh5xBc94rQUZ16ZeoGnaCpM/nee YkLsBH4I2LHP7e9zysCKsq+f6B//B8AEaT9oxhdNwLoC6tc7aJR/WV25TdM1PC4BadJK 0twaPYEFXnJKc8LaRqnckqfwsN6R89Cgh/gsfhH5BuuLyPeNmYcR/fyc+D/Ar1IOd8Xr 8jfg== X-Gm-Message-State: APt69E3epcBNmfb/cVt4zH1YnjE5xxhcltGL0Jel4W+5hqTYKCgpaSw+ Ec13I03XVgmappvYgMhjJW5haPqGJMht1YBFFsc= X-Google-Smtp-Source: ADUXVKJJb5luf24cmwMda5rjfH1xAkRhW15IiTc7xGN1ubBCuWqYxknrl5zTbzXSYZ6nuQDJocbWj1y+qTDxcM0XYDk= X-Received: by 2002:a0c:f6d1:: with SMTP id d17-v6mr4358926qvo.67.1529141820861; Sat, 16 Jun 2018 02:37:00 -0700 (PDT) MIME-Version: 1.0 References: <87k1r972fp.wl-bordjukov@gmail.com> <87po11i0he.fsf@gmail.com> <83d8f202-8842-56fe-0350-5f2fa9a01d67@yandex.ru> In-Reply-To: From: Bozhidar Batsov Date: Sat, 16 Jun 2018 12:36:49 +0300 Message-ID: Subject: Re: bug#31760: 26.1; ruby-mode enables flymake-rubocop by default if the rubocop executable exists To: Petko Bordjukov Content-Type: multipart/alternative; boundary="0000000000000b30fb056ebf13a0" X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 31760 Cc: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= , 31760@debbugs.gnu.org, Dmitry Gutov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) --0000000000000b30fb056ebf13a0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 wrote: > > > On Sat, 16 Jun 2018 at 12:07, Petko Bordjukov wrote= : > >> > So... First of all, there is the variable >> ruby-flymake-use-rubocop-if-available, to satisfy the individual prefere= nce >> 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 tha= t > some project use RuboCop and some don't. I haven't seen almost any projec= ts > 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 standar= d >> - 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 developme= nt > 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'r= e > putting some useful tools in the hands of Emacsers - that's quite differe= nt > from what we've been doing historically here and there. > > >> >> Cheers, >> P. >> >> On Fri, Jun 15, 2018 at 8:54 PM, Bozhidar Batsov >> 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 o= f >> 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 wrote: >> >> >> >> On 6/8/18 9:42 PM, Jo=C3=A3o T=C3=A1vora wrote: >> >> > Petko Bordjukov 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 th= at >> >> >> Rubocop generates are not raised by Ruby I consider them not >> adopted by >> >> >> the Ruby community by default. Based on that, I propose that eithe= r >> >> >> 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 ou= t >> >> there (but probably not). >> >> >> >> Maybe Bozhidar has something to say on this? >> > --0000000000000b30fb056ebf13a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 (whi= ch is 80 by default in so many languages and you can obviously change) is s= ome big problem.=C2=A0

Frankly, as far as I'm concer= ned you're making some counter arguments to your points. I acknowledge = that some aspects of the default config are controversial and that's go= ing to addressed soon, but I think that also applies to most non-trivial li= nt tools. In the end of the day the value you get out of project consistenc= y always outweighs some small initial investment in a tweaking some config.= =C2=A0

On Sat, 1= 6 Jun 2018 at 12:31, Bozhidar Batsov <bozhidar@batsov.com> wrote:


O= n Sat, 16 Jun 2018 at 12:07, Petko Bordjukov <bordjukov@gmail.com> wrote:
=
> So... First of all, there is the variab= le ruby-flymake-use-rubocop-if-available, to satisfy the individual prefere= nce 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 experi= ence, so your comment is subjective by default. :-)=C2=A0

> 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 p= roject 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 (especia= lly in a professional setting) in recent years
and looking at its= rising popularity I guess the usage will grow.=C2=A0=C2=A0

> The vast majority of checks are actually pretty much community standar= d - Ruby produces only a minimal amount of lint warnings, RuboCop has exten= ded 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 upstrea= m, as this would tie the language development cycle to the tooling developm= ent cycle. Linters are supposed to be downstream projects that can evolve i= ndependently (it's the same with all Java linters, Python linters, ES l= inters, etc).
=C2=A0
To add t= o 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 care= fully checked that layout config is Emacs compatible.=C2=A0
=C2= =A0

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.

<= div>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 b= y most people, as flycheck is super popular these days). You should really = understand that we can't be making decisions based on the

<= div>=C2=A0

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 g= iven
> the fact that you can simply disable RuboCop with the defcustom mentio= ned.
>
>> Since most if not all of the warnings that
>>> Rubocop generates are not raised by Ruby I consider them not a= dopted by
>>> the Ruby community by default.
>
> You know this thing is configurable, right? ;-) The vast majority of c= hecks
> are actually pretty much community standard - Ruby produces only a min= imal
> amount of lint warnings, RuboCop has extended linting but also a lot o= f code
> style checking functionality.
>
> I don't really want us to check for RuboCop config files (those ar= e
> 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=C3=A3o T=C3=A1vora wrote:
>> > Petko Bordjukov <bordjukov@gmail.com> writes:
>> >
>> >> Emacs 26.1 enables flymake-rubocop by default if the rubo= cop executable
>> >> is present in the system. Since most if not all of the wa= rnings that
>> >> Rubocop generates are not raised by Ruby I consider them = not adopted by
>> >> the Ruby community by default. Based on that, I propose t= hat either
>> >> using Rubocop by default is turned off, or at least a mor= e 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 ca= n
>> abort if no ruby-rubocop-config file is found. That would certainl= y 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?
--0000000000000b30fb056ebf13a0-- From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 16 11:32:33 2018 Received: (at 31760) by debbugs.gnu.org; 16 Jun 2018 15:32:33 +0000 Received: from localhost ([127.0.0.1]:51825 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fUDBp-0004tt-2s for submit@debbugs.gnu.org; Sat, 16 Jun 2018 11:32:33 -0400 Received: from mail-wm0-f49.google.com ([74.125.82.49]:38985) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fUDBn-0004tg-Ip for 31760@debbugs.gnu.org; Sat, 16 Jun 2018 11:32:31 -0400 Received: by mail-wm0-f49.google.com with SMTP id p11-v6so8445766wmc.4 for <31760@debbugs.gnu.org>; Sat, 16 Jun 2018 08:32:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-transfer-encoding; bh=jLq3liXOXeoUbQjS3EiKsCPSmQW6j/hQ3oRlXLe0lx8=; b=S6SKIAPAb5yhNqJ2DxkmYWtk8JQ8zixwUHNzN4ii8InhOqWHj8Kty3pCkHDqJG5ugE 8u8pdi/fb/GIMPfm3+Q8I0yDN2Oie8CyMoEseACgibnEECIyXFYvAkwqzU2TC6Hyl4Cv LJ9oFTvkAQHeEGKwUtFvHcrN3LA0HfdWTBOb6aWkN69C1+MJaFxoL8erYvqWxV5ktWH2 MKMN0i8ZqbJdQbzNl5zdU2A0jp3AdHk/736PqyEDSEHLE59t0l8d+Bs2Juv3ljWF1Ohm z2KBum53Jc5/PIxjRkO4oOj0q9/JeFyuZE0ld3U4NhBYAErrBT33frMBI9Boe92s2289 F9YA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references :user-agent:date:message-id:mime-version:content-transfer-encoding; bh=jLq3liXOXeoUbQjS3EiKsCPSmQW6j/hQ3oRlXLe0lx8=; b=T2edn7VG4H/qQDMQiDRonm0LB+f5gdw/SxVr6CaA/+g3SxW6fF4/RHJZCiGJuZQdh5 RXdWKRMqtqHoW0QPq8JBrYJtuzzfw8g+5cXV7T9FO8HltcL9uyC2qyX8OLDyWjIpbJJF IfZXy+xtf0te8sSNtsZtRh8Ft5oOolOLco3gq2hPDluqnf2hb3jB3ElFKDW8pdA8Ov3d CywA+naWpE7wL+Zokup357k37nGgvIBCH5TqcRcdu3GTwQIxk3jqnyLJ5LUIq4YPthcg Rj6S7w8iITo+FiQptDZhW8A7MBQn51hCSqEHzZ9+3y8egsRwTrK2ehiLjJPUiq+QtUL8 1JHg== X-Gm-Message-State: APt69E3HgDmQBFOolKs/lsI4V3UlPQYxvMHLAbMe2eq7gtWHN5trITGG jZr7mAjuj+dKMjrI8ZHeV+xc1ytO X-Google-Smtp-Source: ADUXVKIzkas9UPuv/5j/6q9YrM6QD9RnnaODcEELZjTdSOqLDcyj//qsMO1k53oz+VhHTL/youvkCg== X-Received: by 2002:a1c:d543:: with SMTP id m64-v6mr3897322wmg.12.1529163145371; Sat, 16 Jun 2018 08:32:25 -0700 (PDT) Received: from lolita.yourcompany.com (188.139.62.94.rev.vodafone.pt. [94.62.139.188]) by smtp.gmail.com with ESMTPSA id n21-v6sm3015397wmc.42.2018.06.16.08.32.24 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 16 Jun 2018 08:32:24 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= To: Petko Bordjukov Subject: Re: bug#31760: 26.1; ruby-mode enables flymake-rubocop by default if the rubocop executable exists In-Reply-To: (Petko Bordjukov's message of "Sat, 16 Jun 2018 12:07:36 +0300") References: <87k1r972fp.wl-bordjukov@gmail.com> <87po11i0he.fsf@gmail.com> <83d8f202-8842-56fe-0350-5f2fa9a01d67@yandex.ru> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Date: Sat, 16 Jun 2018 16:32:21 +0100 Message-ID: <87602ihhmi.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 31760 Cc: 31760@debbugs.gnu.org, Bozhidar Batsov , Dmitry Gutov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.9 (/) Petko Bordjukov 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) ...)) ...) =20=20 Won't this suffice as a per-project (almost zero) configuration? Jo=C3=A3o =20=20 From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 16 15:47:57 2018 Received: (at 31760) by debbugs.gnu.org; 16 Jun 2018 19:47:58 +0000 Received: from localhost ([127.0.0.1]:52109 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fUHAz-0006h0-FL for submit@debbugs.gnu.org; Sat, 16 Jun 2018 15:47:57 -0400 Received: from mail-qt0-f178.google.com ([209.85.216.178]:33141) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fUHAx-0006gn-2A for 31760@debbugs.gnu.org; Sat, 16 Jun 2018 15:47:56 -0400 Received: by mail-qt0-f178.google.com with SMTP id l10-v6so12079593qtj.0 for <31760@debbugs.gnu.org>; Sat, 16 Jun 2018 12:47:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=fPOHXcGPwcPflAx9aAlH352R5nyjzDC2xd/qDR/bQQU=; b=WX8sKJHDhr1b4Z45d0DaMZqdeWb07Mo0GScL39TVUA4TjoERgdmESnmA0seK4kB0SU oUrJuz5YZNJjFarwzeSU7aUz6CYOiWRh5GIxQmjv/MI4wH+K+8g7T92Bo4JCdZxd9fcl 6AcJkZr7C2/YhIJ1eZ0nOOzKxKkqmEZAUQgMe2E7Wa6cLdHWn9kUQ4lr+pNtqI+vjN0T jbHgeQXESgvh6do/ifDhd1jJdKrlNXiLaJ5AXx1QJdWA/OlIZwP2Ol/oN37oLOdK4qo5 YDYcsq/agXKfvwnjPzjvcX1XzBNvquT0y1YpkVu/SKdts+BomS2UL8EE7NxrqPwE292F mhaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=fPOHXcGPwcPflAx9aAlH352R5nyjzDC2xd/qDR/bQQU=; b=iKuSMSiT2byqhWXnir9CUH/uMoH7SwZ4VuanA+5uUr4zQfs3uPat/UABcg0nXoyN9X 1bPUZ4pPp4r0XU1+IfMd4PKJ4pBCYnr8djlO8JtZuj0f3bNeq4gMbZ/zPm9xIh8Af/yX k1a8BIh3G1mK2J0U4/VNeqJgFiGsbZ/8ZapDqjhMgNAFrEWakxzcOvZGP/AFxEUuA3Iz T/pbZr/RdXep7tgV5n4Ay/mgiUvajPPgLh3S5IFgUH5VltSoWFfTYw+EIWyxYPDmfODP ZONyhey5CZO8WekLu0O6zoRHn2wgj7tya/cP9PoLrgeSkQm7d5UfKodxkVMUjw8bDpb/ 5w2w== X-Gm-Message-State: APt69E25lGd8rauD5KUQFctYUwpO4xhQevXr8gMOzb07A7YCrbjkLiQP bTzSmBwYaS2q83xyqJCP6efnwSJYvyJ36U8k8Lc= X-Google-Smtp-Source: ADUXVKLAHse/deuTKyQeHe0yCnFOQDcUfEPm9Ks1diq+4jl8i/9Wjnewt+mu+wZ1Oq1qMj/3fIgyIH3GfHkxqpqAxlk= X-Received: by 2002:a0c:d28f:: with SMTP id q15-v6mr5804314qvh.65.1529178469559; Sat, 16 Jun 2018 12:47:49 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:aed:26a4:0:0:0:0:0 with HTTP; Sat, 16 Jun 2018 12:47:48 -0700 (PDT) In-Reply-To: References: <87k1r972fp.wl-bordjukov@gmail.com> <87po11i0he.fsf@gmail.com> <83d8f202-8842-56fe-0350-5f2fa9a01d67@yandex.ru> From: Petko Bordjukov Date: Sat, 16 Jun 2018 22:47:48 +0300 Message-ID: Subject: Re: bug#31760: 26.1; ruby-mode enables flymake-rubocop by default if the rubocop executable exists To: Bozhidar Batsov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 31760 Cc: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= , 31760@debbugs.gnu.org, Dmitry Gutov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > So, you're basically saying that it's a big deal to write class documenta= tion 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 cont= roversial 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 ou= t 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 popularit= y 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 wro= te: > Btw, I forgot to comment on the screenshot. So, you're basically saying t= hat > it's a big deal to write class documentation and that it's just some nois= e > (!!!) and that some default line length (which is 80 by default in so man= y > 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 y= ou > 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 wrote= : >> >> >> >> On Sat, 16 Jun 2018 at 12:07, Petko Bordjukov wrot= e: >>> >>> > So... First of all, there is the variable >>> > ruby-flymake-use-rubocop-if-available, to satisfy the individual pref= erence >>> > 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 defaul= t. >> :-) >>> >>> >>> > 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 th= at >> some project use RuboCop and some don't. I haven't seen almost any proje= cts >> 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 standa= rd >>> > - Ruby produces only a minimal amount of lint warnings, RuboCop has e= xtended >>> > 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 developm= ent >> cycle to the tooling development cycle. Linters are supposed to be >> downstream projects that can evolve independently (it's the same with al= l >> 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 checke= d >> 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 s= eems >> 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 differ= ent >> from what we've been doing historically here and there. >> >>> >>> >>> Cheers, >>> P. >>> >>> On Fri, Jun 15, 2018 at 8:54 PM, Bozhidar Batsov >>> 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 adopte= d >>> >>> 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 wrote: >>> >> >>> >> On 6/8/18 9:42 PM, Jo=C3=A3o T=C3=A1vora wrote: >>> >> > Petko Bordjukov 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 eith= er >>> >> >> 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 o= ut >>> >> there (but probably not). >>> >> >>> >> Maybe Bozhidar has something to say on this? From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 16 15:54:27 2018 Received: (at 31760) by debbugs.gnu.org; 16 Jun 2018 19:54:27 +0000 Received: from localhost ([127.0.0.1]:52113 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fUHHH-0006pg-FA for submit@debbugs.gnu.org; Sat, 16 Jun 2018 15:54:27 -0400 Received: from mail-qt0-f176.google.com ([209.85.216.176]:41406) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fUHHF-0006pS-QV for 31760@debbugs.gnu.org; Sat, 16 Jun 2018 15:54:26 -0400 Received: by mail-qt0-f176.google.com with SMTP id y20-v6so12074230qto.8 for <31760@debbugs.gnu.org>; Sat, 16 Jun 2018 12:54:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=U9AdSYtDZPFiSj112ZdG0WQha6PJ9nYGZt/8FoaT+0c=; b=E5+Km/7Bw+32UsoAZwwKCbtjN68TuswKSBlvUTzSMx0pHIGzDBj26+1XtO7fPexP+n NNfLDVMN7QphfvsxWis6EMWRfub7Vyh1UM/Ae4bA8kHiP0SpDFd6qQTd/P/WWn+neXCR PTI3cBUVE1qLXX+MnCrppL+fdrZ39l6Ug3TRO3NTVOHSHwuMV6KwEj0vKNvPcq6QB92I kZYhvCmjr65naDzCFnlO1r1Ydtoj/95W5RyXsAKimyJcThOQhtDIz2WVLo8+RBavowNg itKc9KYLgXwwu/vZ+Koy82O0Iw3S2eDHd7KEC+u1NqGld/JazWWa9LBPRlN1zqM8SwWx lXXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=U9AdSYtDZPFiSj112ZdG0WQha6PJ9nYGZt/8FoaT+0c=; b=Yon2/Olz08+fXTApfGUPQhuch6+I1btoSHYoV27pVr5fEasqDsiCe8aCB6t8cXP6nh hm0FgjjUZBB23ibAsl5IHm2kE6INuk1hEscI9pj6zMuifUgjtD5JrSsADhICB7BG49gH I7NyhPiKeFQ3+09e0H2euxiI6QyA7kffC7E7HkUzLEGJBMydANZQWnTC43nc5WNAX1Fn UDJUxsjwURAL2jRm2AM6V/pXg9pjgal8VH+vNTKbemeQdejmCxCsrryIKFqUB2nu2TzC gdaesUu2C54dvBIMlUzv+7sEqp5N4FHMP7wo+8cRTlVkZPCwEcRtXQW2PKeRvMK76FXd jk0g== X-Gm-Message-State: APt69E3QuK7dqW9Vopwozte9ejB+9WeazQJFz/IpKkUs1EvaKXkKWWTr OSgx866K8gAoaHkjj0VqG2xHYSsliZ7sGb5QQao= X-Google-Smtp-Source: ADUXVKIeLiBJZz206u3jIJqGN/C4nrw2xvXGnk2mCxPOKd6m6i+YG0HXYa1FD9Wsj2eKO8eC6hhPDZ8I886UwZXkiTE= X-Received: by 2002:ac8:2c23:: with SMTP id d32-v6mr6032374qta.54.1529178860401; Sat, 16 Jun 2018 12:54:20 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:aed:26a4:0:0:0:0:0 with HTTP; Sat, 16 Jun 2018 12:54:19 -0700 (PDT) In-Reply-To: <87602ihhmi.fsf@gmail.com> References: <87k1r972fp.wl-bordjukov@gmail.com> <87po11i0he.fsf@gmail.com> <83d8f202-8842-56fe-0350-5f2fa9a01d67@yandex.ru> <87602ihhmi.fsf@gmail.com> From: Petko Bordjukov Date: Sat, 16 Jun 2018 22:54:19 +0300 Message-ID: Subject: Re: bug#31760: 26.1; ruby-mode enables flymake-rubocop by default if the rubocop executable exists To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 31760 Cc: 31760@debbugs.gnu.org, Bozhidar Batsov , Dmitry Gutov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > I'd just like to chime in briefly with two points: Thank you for the advice, Jo=C3=A3o. 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=C3=A3o T=C3=A1vora wrote: > Petko Bordjukov 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=C3=A3o > > From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 16 15:55:31 2018 Received: (at 31760) by debbugs.gnu.org; 16 Jun 2018 19:55:31 +0000 Received: from localhost ([127.0.0.1]:52117 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fUHIG-0006rL-VM for submit@debbugs.gnu.org; Sat, 16 Jun 2018 15:55:30 -0400 Received: from mail-qk0-f171.google.com ([209.85.220.171]:45717) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fUHIE-0006r9-GA for 31760@debbugs.gnu.org; Sat, 16 Jun 2018 15:55:27 -0400 Received: by mail-qk0-f171.google.com with SMTP id c198-v6so7459436qkg.12 for <31760@debbugs.gnu.org>; Sat, 16 Jun 2018 12:55:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=batsov-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=P+3zZ1zthhljMs8NPiYbCGEoISotl3uyhpQ8938ezgU=; b=Am3sTvyprxcAStJzmgIrEn4t7SiAj60A16ct7mxdDayyfoHEQ0UrPfzsft5/egKiOH IHhphKx/eCp/Y/E6nWQ42/jag2I71EWBgEwS495HsUTC97ARZF0J4VJ5+R2XRQ7X9K5/ +HXxnARW9+oh5YbGg9n85NadhTfFW41LuvHPPqFwg1tqtoooYOVuP0McahEJj0Zgrh/N Ejwv/thDwIypwR6DZcfHmV5cD52/rceJ9xs9VNw2C075WvpU1CDBtPTxbQS+q12kyOL4 iS9B25RbfEx7MfpFNA5p7Hd7jntE7+CaRNOWwq27fQlfvYTJofFqkC0TMIgo01SrQQz9 9Kow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=P+3zZ1zthhljMs8NPiYbCGEoISotl3uyhpQ8938ezgU=; b=EKVfbdfmes1T9Zll1GVI2zuflBMFKOulX583Ft6P2TqUr7enYEHHdvfi2lis/HPUQ3 OjioKyJer7hTC7cuUe16gh2g94SD+TbkXpKHUpvmg1Q+7jv8namWntHsKFBoHNuBZhcf rCp5hME+kwLrP12XbZSTKqZxDzA+CQtKmo7o1NLyzs8Y6fZritj9WJzWW2BXYObTsIHC 3q5qfV3ewAr2MY6wY++VhCbCdSKrZZMBL7tb7n9omVIj1K8a/dA3tL5ChYdgu3DVihqp txHih8nKpSEhqFlo8+EMviTIfeuEmfljKSW+BcGueWlS3aQBfWSqphNcfWtN27Z5vAJA andA== X-Gm-Message-State: APt69E2S4wGIBeHOJS64Dy+ZD3O6twAjYeM6a6Hsq5SsWLIc+8v+l+h8 KIqU4bw0BULREg/SlkSt3R2EvVKtXPqocZjejW4= X-Google-Smtp-Source: ADUXVKKpTMf0hxa+kcu4loZjpU8vuapyRlNm7VUn8th0olHB/6oq60BG5saYPbejpJrWDncjkSsASyYtZ9NKfsWMN68= X-Received: by 2002:a37:83c4:: with SMTP id f187-v6mr5297299qkd.189.1529178920857; Sat, 16 Jun 2018 12:55:20 -0700 (PDT) MIME-Version: 1.0 References: <87k1r972fp.wl-bordjukov@gmail.com> <87po11i0he.fsf@gmail.com> <83d8f202-8842-56fe-0350-5f2fa9a01d67@yandex.ru> In-Reply-To: From: Bozhidar Batsov Date: Sat, 16 Jun 2018 22:55:09 +0300 Message-ID: Subject: Re: bug#31760: 26.1; ruby-mode enables flymake-rubocop by default if the rubocop executable exists To: Petko Bordjukov Content-Type: multipart/alternative; boundary="00000000000060367d056ec7b6ab" X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 31760 Cc: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= , 31760@debbugs.gnu.org, Dmitry Gutov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) --00000000000060367d056ec7b6ab Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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 t= o > 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 y= ou > 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 an= d > > > 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 i= n > 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 > 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 t= o > > 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 > wrote: > >> > >> > >> > >> On Sat, 16 Jun 2018 at 12:07, Petko Bordjukov > 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 an= d > >>> 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 recen= t > >> 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 th= at > >> 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 hav= e > >> 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 real= ly > >> 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 > >>> wrote: > >>> > Why would have RuboCop installed and not what to use it? > >>> > > >>> > I think the check is perfectly fine in its current state, especiall= y > >>> > 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 o= f > >>> > checks > >>> > are actually pretty much community standard - Ruby produces only a > >>> > minimal > >>> > amount of lint warnings, RuboCop has extended linting but also a lo= t > 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 wrote= : > >>> >> > >>> >> On 6/8/18 9:42 PM, Jo=C3=A3o T=C3=A1vora wrote: > >>> >> > Petko Bordjukov 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 ca= n > >>> >> abort if no ruby-rubocop-config file is found. That would certainl= y > >>> >> 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? > --00000000000060367d056ec7b6ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Well, seems this is one of those discussions that can go o= n forever and no one can really make a solid enough argument to support the= ir point of view.

As Emacs 26.1 is out this can't re= ally 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 a= ll the same to me. I like the current state of affairs, as I'm passiona= te about exposing more people to good programming style,
but I do= n't really have time to waste on this debate. I'd rather spend my t= ime elsewhere fixing some actual problems.=C2=A0

On Sat, 16 Jun 2018 at 22:47, Petko Bordj= ukov <bordjukov@gmail.com>= wrote:
> So, you're basical= ly 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 ar= guments to your points. I acknowledge that some aspects of the default conf= ig are controversial and that's going to addressed soon, but I think th= at also applies to most non-trivial lint tools. In the end of the day the v= alue 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 RuboCo= p 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 (esp= ecially in a professional setting) in recent years and looking at its risin= g 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 ca= refully 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/1002161955= 43129951

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 s= aying that
> it's a big deal to write class documentation and that it's jus= t 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 ar= guments 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 valu= e 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 ind= ividual 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?<= br> >>>
>>> Because you are working both on projects that have adopted Rub= oCop and
>>> projects that have not? In my experience the latter are more t= han 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 c= hanged.
>>
>>
>> Or you can simply use `.dir-locals.el` per project as you just agr= eed that
>> some project use RuboCop and some don't. I haven't seen al= most 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.<= br> >>>
>>>
>>> > The vast majority of checks are actually pretty much comm= unity standard
>>> > - Ruby produces only a minimal amount of lint warnings, R= uboCop has extended
>>> > linting but also a lot of code style checking functionali= ty.
>>>
>>> I do not agree, especially with the 'pretty much community= standard'
>>> part. If they were, they'd be part of the warnings incorpo= rated 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 de= velopment
>> cycle to the tooling development cycle. Linters are supposed to be=
>> downstream projects that can evolve independently (it's the sa= me 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'v= e carefully checked
>> that layout config is Emacs compatible.
>>
>>>
>>>
>>> Here is an example of the modifications necessary for even a s= imple
>>> file in a project that does not adopt RuboCop's style guid= e:
>>> https://social.petko.me/@petko/1002136= 85659065450
>>>
>>> Again, I appreciate this feature, but do not leave it on by de= fault --
>>> 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 somet= hing'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 an= d that we're
>> putting some useful tools in the hands of Emacsers - that's qu= ite 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&g= t;
>>> wrote:
>>> > Why would have RuboCop installed and not what to use it?<= br> >>> >
>>> > I think the check is perfectly fine in its current state,= especially
>>> > given
>>> > the fact that you can simply disable RuboCop with the def= custom
>>> > mentioned.
>>> >
>>> >> Since most if not all of the warnings that
>>> >>> Rubocop generates are not raised by Ruby I consid= er 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 produc= es 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 fi= les (those are
>>> > hierarchical and won't necessarily be in the root of = your current
>>> > project
>>> > anyways) - I think the current check + config is sufficie= nt.
>>> >
>>> > On Fri, 15 Jun 2018 at 17:16, Dmitry Gutov <dgutov@yandex.ru> wrote:=
>>> >>
>>> >> On 6/8/18 9:42 PM, Jo=C3=A3o T=C3=A1vora wrote:
>>> >> > Petko Bordjukov <bordjukov@gmail.com> writes:
>>> >> >
>>> >> >> Emacs 26.1 enables flymake-rubocop by defaul= t 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 c= onsider them not
>>> >> >> adopted by
>>> >> >> the Ruby community by default. Based on that= , I propose that either
>>> >> >> using Rubocop by default is turned off, or a= t least a more
>>> >> >> inteligent
>>> >> >> per-project Rubocop detection scheme is impl= emented.
>>> >> >>
>>> >> > 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 w= ould certainly
>>> >> work
>>> >> for me, but would maybe conflict with the general usa= ge of Rubocop out
>>> >> there (but probably not).
>>> >>
>>> >> Maybe Bozhidar has something to say on this?
--00000000000060367d056ec7b6ab-- From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 18 10:02:21 2018 Received: (at 31760) by debbugs.gnu.org; 18 Jun 2018 14:02:21 +0000 Received: from localhost ([127.0.0.1]:55129 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fUujc-0004Mo-NW for submit@debbugs.gnu.org; Mon, 18 Jun 2018 10:02:21 -0400 Received: from mail-wr0-f177.google.com ([209.85.128.177]:36368) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fUujb-0004Jf-3n for 31760@debbugs.gnu.org; Mon, 18 Jun 2018 10:02:19 -0400 Received: by mail-wr0-f177.google.com with SMTP id f16-v6so16993830wrm.3 for <31760@debbugs.gnu.org>; Mon, 18 Jun 2018 07:02:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=9ntr4J+T53QEOtGqMbk3vgxtvFePJks+CApmG/hKyvU=; b=jEZv6sK3ePV3JPyLCuf3jwvJqJEy1hqo/m1CJuAxfScydlPlQ78b+E/m1HZ5F/tXBx QRPyvzRSe1NtJtm8pQaiugFLoSXOlbmulHvuyUEEWGePCYLzifMjToIUh0R2a4RVm82X v8J+Acdf5l39aUeJ+uVraoSnEHfCNrpdvC4goZBLvyvgUUporYuVk2/roeEmvH/kZJEm D8LVA6g1op38nrAetJnthVxuoedh0cfCmDFAj3Pwl45khLKsmnU8TJ6l+Yffziz9oIcn HQ/AHjH1ffNYnnOvrludnBaKzgqASIzx61bs1SWg6+yW5xETKJe8GLSvQEawHp8TkmGO UdKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=9ntr4J+T53QEOtGqMbk3vgxtvFePJks+CApmG/hKyvU=; b=bFmJ8B0VvD9CQEYWzDbMCL56kPKEH2vhWy+inXPrNdHju3JKVYD9xdgRvDQTx01+CI t2/fbREO+z6vMhCdg9zmsWxzSaa8SoSy+fBYMRMRuA+2hbK3203/KcL77xVZJfMDqEKj qOLI0WWvzYimR40a2sWUPlnEcS9R7jDK1Eqk1xgGul9X+7DwpjNXCSdbRdM1B1NqTbw+ BYLNCJ38xdfYBAgoIYtCcMeQqkaCVU6GvJ13A17gX+M7V2ZosXDlGd0v9HEyMOAZd5uO uCVbv0FnXpvrY02lwB0/qVqmM9GDVsOnp+iK+WTQMmjeoGNro9yNWE1VuUbK6MFAngd5 O58w== X-Gm-Message-State: APt69E2Naki509UObbtdme7eF/5Nu0+yfvd9vyO6VVTh1PNVShk1TgKq gecXvN9LaNnGPLX1EwM3RuYiXR3G X-Google-Smtp-Source: ADUXVKLHQUoe4MyCZLVq+tpEFMwgQhGLNJKW90t2ZI1eOkcE0OM6j9rvv0n9hEaaUD906D8a11zprw== X-Received: by 2002:adf:bbcd:: with SMTP id z13-v6mr10929191wrg.183.1529330533005; Mon, 18 Jun 2018 07:02:13 -0700 (PDT) Received: from [192.168.0.200] ([212.50.99.193]) by smtp.googlemail.com with ESMTPSA id b124-v6sm11387178wmf.11.2018.06.18.07.02.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Jun 2018 07:02:11 -0700 (PDT) Subject: Re: bug#31760: 26.1; ruby-mode enables flymake-rubocop by default if the rubocop executable exists To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= , Petko Bordjukov References: <87k1r972fp.wl-bordjukov@gmail.com> <87po11i0he.fsf@gmail.com> <83d8f202-8842-56fe-0350-5f2fa9a01d67@yandex.ru> <87602ihhmi.fsf@gmail.com> From: Dmitry Gutov Message-ID: <4819c282-6132-e5d0-8771-0b558ee58e70@yandex.ru> Date: Mon, 18 Jun 2018 17:02:07 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <87602ihhmi.fsf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 31760 Cc: 31760@debbugs.gnu.org, Bozhidar Batsov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) 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. From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 18 10:09:22 2018 Received: (at 31760) by debbugs.gnu.org; 18 Jun 2018 14:09:22 +0000 Received: from localhost ([127.0.0.1]:55133 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fUuqP-0004W6-N1 for submit@debbugs.gnu.org; Mon, 18 Jun 2018 10:09:22 -0400 Received: from mail-qt0-f169.google.com ([209.85.216.169]:34434) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fUuqL-0004Vp-0c for 31760@debbugs.gnu.org; Mon, 18 Jun 2018 10:09:18 -0400 Received: by mail-qt0-f169.google.com with SMTP id d3-v6so15213386qto.1 for <31760@debbugs.gnu.org>; Mon, 18 Jun 2018 07:09:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=batsov-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4doYFZfGrVC6pkNzyB9nrwumwCtt3YBxxLy3kC0LvkQ=; b=gtTc1PKH+lt/4I23tS06uZfeHApWddC5Vt2R6t2+Ranrbl2XHEGsM44WyYyrG6PwlV /OmsyhKu8SWs6p+YPmwjFvZcT/YMPA64H0Vx2Ab5K9JBMtFKz/Y7c3bPZQ653J8KzAAp cNKBkcMoKkgJg3wrfvMOOvNw8y2JhnGLqeFntb5pis3y1rRyRTz9DJXB2nTdP7ZPZ5dm qU3WLFEW1zu11IdeC+1/Ie4yVJJpcPOkpw5DvfM2t9lGN7kUw++9zRBDU/KmjAn7MDbE eZDzsjpNrf997azDsdUGY+oKXlTnimsREemKdcgmIb4jNOUtCQCVjHAKhqBotWSz2vuh ytgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4doYFZfGrVC6pkNzyB9nrwumwCtt3YBxxLy3kC0LvkQ=; b=VO0SIZZWtYhoTLYvRmNAfUCcb+7lN5a3bVFX1YdTRWPbI0pd1ZqxASjsBKJ7z7Fq5v 3oDq2f0E0qAg/coRVkHiEEaw5ExXwWM4DzHIwW40Cn2qsI/tZ/YVtVpbHeJ4kYI2N8hq WQ4pFOO1gi4U7YTwvqRsAZebfvPBJdna4Wu2r9YIRK81ASlOGnJMUUG3N50QxJ9wwxi7 sBOgRpmD0A4U1ZSWOQvlHbshQOZV5F2xwzR4tkG9KlMI++oQCdlLxv4/9+2IqWadrdi7 1OX9vj2yx3ZqeZkc+oT7uJvK4ZkRrfnbhnWi6q7PQhxLQiE7n6objAWRXPW8CW4qH3kn iAcw== X-Gm-Message-State: APt69E2BNBTPpqlsQvn+ppBzC7qExeCD/YfAZ4UVesaR1oSgYT4x1yf0 oUAjuOrdD9NEhPnUcl3WPUFYtGWNdfseJ9LpOJc= X-Google-Smtp-Source: ADUXVKJRcGplhzi87b6+OiEvKdHx709Ok9s4vzTc5geNty0JcHSA31N0Dof2U2Re/JMFhtz+nv3uEFEsufxv3tDGqZ4= X-Received: by 2002:ac8:264d:: with SMTP id v13-v6mr10946801qtv.228.1529330951535; Mon, 18 Jun 2018 07:09:11 -0700 (PDT) MIME-Version: 1.0 References: <87k1r972fp.wl-bordjukov@gmail.com> <87po11i0he.fsf@gmail.com> <83d8f202-8842-56fe-0350-5f2fa9a01d67@yandex.ru> <87602ihhmi.fsf@gmail.com> <4819c282-6132-e5d0-8771-0b558ee58e70@yandex.ru> In-Reply-To: <4819c282-6132-e5d0-8771-0b558ee58e70@yandex.ru> From: Bozhidar Batsov Date: Mon, 18 Jun 2018 17:09:00 +0300 Message-ID: Subject: Re: bug#31760: 26.1; ruby-mode enables flymake-rubocop by default if the rubocop executable exists To: Dmitry Gutov Content-Type: multipart/alternative; boundary="0000000000001c3f66056eeb1c99" X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 31760 Cc: Petko Bordjukov , =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= , 31760@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) --0000000000001c3f66056eeb1c99 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 wrote: > On 6/16/18 6:32 PM, Jo=C3=A3o T=C3=A1vora 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 mos= t > > importantly, nobody objected (much less I, who welcomed the enthusia= sm > > for using the new API). So even though Emacs 26.1 is a month old, t= he > > 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. > --0000000000001c3f66056eeb1c99 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 peopl= e have global RuboCop configs).=C2=A0

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.=C2=A0

On Mon, 18 Jun 2018 at 17:02, Dmitry Gutov <dgutov@yandex.ru> wrote:
On 6/16/18 6:32 PM, Jo=C3=A3o T=C3=A1vora wrote:

>=C2=A0 =C2=A0 There was little discussion on this before 26.1 because i= t was all
>=C2=A0 =C2=A0 kinda rushed, because Dmitry is the maintainer of ruby-mo= de, and most
>=C2=A0 =C2=A0 importantly, nobody objected (much less I, who welcomed t= he enthusiasm
>=C2=A0 =C2=A0 for using the new API).=C2=A0 So even though Emacs 26.1 i= s a month old, the
>=C2=A0 =C2=A0 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 >=C2=A0 =C2=A0 having flymake backends separate, so instead of having >=C2=A0 =C2=A0 ruby-flymake-auto checks the defcustom, I advise Petko to= use a
>=C2=A0 =C2=A0 directory-local variable in the project configuring
>=C2=A0 =C2=A0 flymake-diagnostic-functions to either ruby-flymake-simpl= e or
>=C2=A0 =C2=A0 ruby-flymake-rubocop, i.e. some .dir-locals.el containing= this
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 (ruby-mode . (...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 (flymake-diagnostic-functions ruby-flymake-simple)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 ...))
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...)
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 Won't this suffice as a per-project (almost zero) con= figuration?

That still leaves the question of a reasonable default. But if you ask
me, removing the custom variable a making the "auto" behavior &qu= ot;always
on" will also be good.
--0000000000001c3f66056eeb1c99-- From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 25 10:36:45 2018 Received: (at 31760-done) by debbugs.gnu.org; 25 Dec 2018 15:36:45 +0000 Received: from localhost ([127.0.0.1]:36368 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gbolB-00038m-E1 for submit@debbugs.gnu.org; Tue, 25 Dec 2018 10:36:45 -0500 Received: from mail-wr1-f54.google.com ([209.85.221.54]:36535) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gbol9-00038V-Bb for 31760-done@debbugs.gnu.org; Tue, 25 Dec 2018 10:36:43 -0500 Received: by mail-wr1-f54.google.com with SMTP id u4so13834454wrp.3 for <31760-done@debbugs.gnu.org>; Tue, 25 Dec 2018 07:36:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=icv2099mW5JH1Xun956U719KpkdPlmdxsN2z9+P+HUE=; b=IAW9jU99yysfbOMczkaPLEtaUFoLho9pdodVh7QAUBccxJ9q65e7X0VAzu4S06ILtF 990+t/0dY65bxatcbijhl0gbDaMKmyal+ksgLq8mWaQLtyaBvSOShv+tw8tqBjwihAzX BtmnFJeCrQtnL75I+Zt1xYDUm1IAt3Xdw0k3D2T1RAZFMIx+azJtNwY0kvZHlQNlQW0d zRnbrUsffizbtdqscKqHKtL6Ym5Gt01lyNxUJX0uOt/XPZqrlz35b3ErrsBFgvd0loSe NJFyYlaIeV2U5bRE+VraWxicDHLOL9ReXH1C32bATqjrJzotkNidd8Z+ROzhdFFA0TjW LrTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=icv2099mW5JH1Xun956U719KpkdPlmdxsN2z9+P+HUE=; b=FZBTJfI95Ctcsfqwb24MXFF2JgfgR3dayx4bVuJLYGT0A26/6mb8if5iVc7mWirmgS clu7E72OlCeyEt2AzXrBgRGMKOu2I1JNORXY8OglKrgkphR2C/lZOHWuZ/JnPuN4GwBt Rs9zCCfdcDKtPKT21BK291XcZknPAlF5ZqSnvZR2wN6O8Q1//11NZvF0MHKI50i7HAeO GalK25+wujrPCRoLjMcMEpjJixJyGatIZs8333VezvcLQt7A762QwL/2hwZGdo2ZNLXu gIpoS8jSW+GV94ZSZjXNqhnfNTOUXmeSTL3Wy1+OQvbNMvftClQRbpCJI8htub7yvIeV xoUA== X-Gm-Message-State: AJcUukcN5iAZi1YhlOIC0CUQpQjAPmsB+FRhZJPWILmL1mq/RhsAHEGs 9FiqK0FK/gKzaiMCV9Jw2+gmUNMF X-Google-Smtp-Source: ALg8bN7nL0sYcGJUECWP8jfFyBL46lGItHXj65cyPG3J4tiyfSWfvmSo2xBLVLfhB1SeGFStbHVJpA== X-Received: by 2002:adf:ce02:: with SMTP id p2mr16806846wrn.185.1545752197392; Tue, 25 Dec 2018 07:36:37 -0800 (PST) Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id f2sm20750304wre.34.2018.12.25.07.36.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Dec 2018 07:36:36 -0800 (PST) Subject: Re: bug#31760: 26.1; ruby-mode enables flymake-rubocop by default if the rubocop executable exists To: Bozhidar Batsov References: <87k1r972fp.wl-bordjukov@gmail.com> <87po11i0he.fsf@gmail.com> <83d8f202-8842-56fe-0350-5f2fa9a01d67@yandex.ru> <87602ihhmi.fsf@gmail.com> <4819c282-6132-e5d0-8771-0b558ee58e70@yandex.ru> From: Dmitry Gutov Message-ID: <1b89e59f-369b-86e1-2d5b-6daab8ac82f9@yandex.ru> Date: Tue, 25 Dec 2018 17:36:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:64.0) Gecko/20100101 Thunderbird/64.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 31760-done Cc: Petko Bordjukov , =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= , 31760-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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. From unknown Sun Jun 22 17:12:52 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Wed, 23 Jan 2019 12:24:05 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator