From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Bozhidar Batsov Newsgroups: gmane.emacs.bugs Subject: bug#31760: 26.1; ruby-mode enables flymake-rubocop by default if the rubocop executable exists Date: Mon, 18 Jun 2018 17:09:00 +0300 Message-ID: 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000001c3f66056eeb1c99" X-Trace: blaine.gmane.org 1529331316 24658 195.159.176.226 (18 Jun 2018 14:15:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 18 Jun 2018 14:15:16 +0000 (UTC) Cc: Petko Bordjukov , =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= , 31760@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jun 18 16:15:11 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fUuw2-0006Ic-S8 for geb-bug-gnu-emacs@m.gmane.org; Mon, 18 Jun 2018 16:15:11 +0200 Original-Received: from localhost ([::1]:35003 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fUuy9-0007RJ-RH for geb-bug-gnu-emacs@m.gmane.org; Mon, 18 Jun 2018 10:17:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38044) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fUur8-0001zn-Ug for bug-gnu-emacs@gnu.org; Mon, 18 Jun 2018 10:10:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fUur4-0000pZ-FD for bug-gnu-emacs@gnu.org; Mon, 18 Jun 2018 10:10:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:47237) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fUur4-0000pS-9V for bug-gnu-emacs@gnu.org; Mon, 18 Jun 2018 10:10:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fUur4-0004X8-2s for bug-gnu-emacs@gnu.org; Mon, 18 Jun 2018 10:10:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Bozhidar Batsov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 18 Jun 2018 14:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 31760 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 31760-submit@debbugs.gnu.org id=B31760.152933096217371 (code B ref 31760); Mon, 18 Jun 2018 14:10:02 +0000 Original-Received: (at 31760) by debbugs.gnu.org; 18 Jun 2018 14:09:22 +0000 Original-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 Original-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 Original-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) In-Reply-To: <4819c282-6132-e5d0-8771-0b558ee58e70@yandex.ru> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:147600 Archived-At: --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--