From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Petko Bordjukov Newsgroups: gmane.emacs.bugs Subject: bug#31760: 26.1; ruby-mode enables flymake-rubocop by default if the rubocop executable exists Date: Sat, 16 Jun 2018 22:47:48 +0300 Message-ID: References: <87k1r972fp.wl-bordjukov@gmail.com> <87po11i0he.fsf@gmail.com> <83d8f202-8842-56fe-0350-5f2fa9a01d67@yandex.ru> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1529178372 31719 195.159.176.226 (16 Jun 2018 19:46:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 16 Jun 2018 19:46:12 +0000 (UTC) Cc: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= , 31760@debbugs.gnu.org, Dmitry Gutov To: Bozhidar Batsov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jun 16 21:46:08 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 1fUH9C-00086k-KI for geb-bug-gnu-emacs@m.gmane.org; Sat, 16 Jun 2018 21:46:06 +0200 Original-Received: from localhost ([::1]:52655 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fUHBJ-00060K-Sz for geb-bug-gnu-emacs@m.gmane.org; Sat, 16 Jun 2018 15:48:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47100) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fUHB7-0005yd-UW for bug-gnu-emacs@gnu.org; Sat, 16 Jun 2018 15:48:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fUHB3-0000JN-VD for bug-gnu-emacs@gnu.org; Sat, 16 Jun 2018 15:48:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:44212) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fUHB3-0000JB-Ok for bug-gnu-emacs@gnu.org; Sat, 16 Jun 2018 15:48:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fUHB3-0006hH-HX for bug-gnu-emacs@gnu.org; Sat, 16 Jun 2018 15:48:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Petko Bordjukov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 Jun 2018 19:48:01 +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.152917847825734 (code B ref 31760); Sat, 16 Jun 2018 19:48:01 +0000 Original-Received: (at 31760) by debbugs.gnu.org; 16 Jun 2018 19:47:58 +0000 Original-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 Original-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 Original-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) Original-Received: by 2002:aed:26a4:0:0:0:0:0 with HTTP; Sat, 16 Jun 2018 12:47:48 -0700 (PDT) In-Reply-To: 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:147535 Archived-At: > 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?