From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Aaron Jensen Newsgroups: gmane.emacs.bugs Subject: bug#60186: 29.0.60; ruby-mode indentation of multi-line expressions Date: Sat, 24 Dec 2022 19:12:39 -0500 Message-ID: References: <4e44df18-207c-c7ca-0588-7285f3008dfb@yandex.ru> <358bbd65-9375-04c8-f0a2-24a4383f142e@yandex.ru> <2b4a91e1-bad1-382f-dd64-abf171efb404@yandex.ru> <60e207e0-7378-ad9f-3ef0-99df1c139939@yandex.ru> <902440c7-706a-20e1-55af-4e12e8cdda2c@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4529"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 60186@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Dec 25 01:15:40 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p9Efz-0000zm-Sc for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 25 Dec 2022 01:15:39 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p9EeU-0006Pb-KP; Sat, 24 Dec 2022 19:14:06 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p9EeQ-0006NZ-Jl for bug-gnu-emacs@gnu.org; Sat, 24 Dec 2022 19:14:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p9EeQ-0006s2-Ag for bug-gnu-emacs@gnu.org; Sat, 24 Dec 2022 19:14:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p9EeP-0003iB-Nx for bug-gnu-emacs@gnu.org; Sat, 24 Dec 2022 19:14:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Aaron Jensen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 25 Dec 2022 00:14:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 60186 X-GNU-PR-Package: emacs Original-Received: via spool by 60186-submit@debbugs.gnu.org id=B60186.167192718314110 (code B ref 60186); Sun, 25 Dec 2022 00:14:01 +0000 Original-Received: (at 60186) by debbugs.gnu.org; 25 Dec 2022 00:13:03 +0000 Original-Received: from localhost ([127.0.0.1]:47335 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p9EdS-0003fK-7I for submit@debbugs.gnu.org; Sat, 24 Dec 2022 19:13:02 -0500 Original-Received: from mail-pj1-f43.google.com ([209.85.216.43]:40860) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p9EdN-0003ek-1b for 60186@debbugs.gnu.org; Sat, 24 Dec 2022 19:13:00 -0500 Original-Received: by mail-pj1-f43.google.com with SMTP id c8-20020a17090a4d0800b00225c3614161so4810759pjg.5 for <60186@debbugs.gnu.org>; Sat, 24 Dec 2022 16:12:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=GYmTTB0uzTKIbJmMp5TvwJTNSvSvOe0Dd53uiySZibQ=; b=NwjhOH1SZYvqQM08hdDJN3JMiQ2UF9rS4g5wHMiu9aggAHfB0iNHF+VDHQSrCutSQA HtbimBz8V5TQkMKzO3gBrmiW4Ln++q3NBVAVBHjhXb+4pd0Amszdimpsx5iEaWfnGyWv 3XnGBuhxCHUrV6mbaBZGq+Uf0occTqOzsDQf250sPYSBjfWtKdwpNj4uuONwdMXhiBkG Wf5+DWss/hAcQAb3v7fcfDuhdz0SUoVfQ8pnaH/wwq5JPHuHgXNGU+dIzvvvtkuoDhqc r14Fegqr0HWOJM+4Osk4jVluynWSbFb4dQTm9rbvRhbuwaoR6q+hu92gGK1RUrNyXj1J AQ1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=GYmTTB0uzTKIbJmMp5TvwJTNSvSvOe0Dd53uiySZibQ=; b=wceqdF/nfAKhh6M+Wg7WlCCu+1ijVbVGHsAF0SbkSEQS+Q3aYd1ADJP45mpgbp40XT nN/Hs2DqNOJdFSBMLUAh+FXvzcbcd8CydaLcNYYi8gwVemQz7iwfzUN1MIhKDBcgNBIT Dp4c2rG8CDltWtKWTkMOkE+tYbXmwys8fBDthC4LPH6gctFcw/HHTjw+RgtV45ySXgJH N2/pBXCbm72G752DayW/QlNz9VldgHlvQEDrrjiCXwr6qgAf8fKQ3st555ONd0fOjwQG sFEwqUHSvxtAZO0EPCrVftsWmKOXbn61G6eQiWed730D/BadDsHW6quw2DU80WhQUgH+ HE3Q== X-Gm-Message-State: AFqh2kq3vskEvmJ1LaxZp+lyi+YBjo4dfHou2SRHxU0UJA5bAcK64yME XZjP/vYfz3/REf7AnprXTmeXjKrQ+lXUnabbNNI= X-Google-Smtp-Source: AMrXdXuf6B8uhOdhli53gC8/i7OD1+Knb52pOBYIXwN6v5Hx5kmJvnWLqqOyLpX5Dv/L2NWRxFsQxf2Nb/VnRGgeGFQ= X-Received: by 2002:a17:90b:d8a:b0:223:f336:1519 with SMTP id bg10-20020a17090b0d8a00b00223f3361519mr1097797pjb.198.1671927170999; Sat, 24 Dec 2022 16:12:50 -0800 (PST) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:251820 Archived-At: On Sat, Dec 24, 2022 at 5:47 PM Dmitry Gutov wrote: > > On 24/12/2022 02:17, Aaron Jensen wrote: > > On Fri, Dec 23, 2022 at 5:26 PM Dmitry Gutov wrote: > >> > >> Is that also true for the other "codebases you've seen" referred to in > >> the first message here? > > > > Mostly we work with Rails (and I try to avoid looking at that code as > > much as I can, though I often find myself in there...) and the > > Eventide framework: https://github.com/eventide-project > > Thanks. It's very neat. I couldn't find any big app in there, though. > And that's where the things tend to become more hairy. Funny thing, that. That's intentional. Our client's codebase we built doesn't have any big apps either. Different subject though. > > Given that the two founders of that are on my team we tend to follow > > their indentation and coding style (and it is well-thought out, with > > everything considered with respect to human cognition/eye tracking > > studies/etc.). That's probably the best example I could offer, though > > what you will find in there is that not many lines of code span more > > than one line. They (and we) tend to allow longer lines when the right > > side of the line is less important. > > With code rarely spanning multiple lines, the current indentation logic > of ruby-mode is probably working fine too. We see more in our application (and that's closed source, so I cannot share it). Suffice it to say, it came up enough that all the Emacs users on our team have had trouble with it, so this work will be appreciated. > >>> With either indentation style, the > >>> first argument (which is the most significant one when a method is > >>> properly designed) will have the least presence when scanning. It's > >>> just not a good format in my experience. In our code we take it a step > >>> further and always use parentheses except for in class level "macros". > >> > >> That's also my preference and true of the code I've seen. But "class > >> level macros" are often an important part of projects, be that > >> ActiveRecord validations, or DSL-like calls in Grape (routes, params, etc). > >> > >> So I wonder whether we should alter parenless calls' indentation for the > >> "simplified" style. > > > > I think I would tend towards saying yes, make it simple/like the chef > > codebase. That's consistent and if one wants to line things up, then > > one can use parens, even with class level macros (or use long lines > > and not care). > > All right. In the latest iteration of the patch (attached) I've split > off the block's indentation behavior into a separate option and altered > the indentation of the parenless calls. > > In the more complex cases the results are definitely interesting: > > method arg1, > method2 arg2, > arg3 I don't know what I'd expect here, other than to have a conversation with the dev who wrote it to explain why we use parentheses :) In other words, I'm fine with this indentation and I couldn't even tell you the precedence here off the top of my head. > zzz = method (a + b), > c, :d => :e, > f: g Yeah, this looks right to me too. > >> Though they also like to line up the keyword arguments according to > >> Rubocop's defaults > >> (https://github.com/spree/spree/blob/main/core/app/models/spree/product.rb#L63), > >> something we don't support yet. > > > > This line is rather painful to read and inconsistent with the call > > just below it on line 70. I would certainly not advocate for that. > > I think it's consistent in the sense that the "keyword" section of the > arguments is vertically aligned in both cases. It's a popular Rubocop > rule, apparently. > > Whether it's useful, though, I'm doubtful too. > > >> Do you have a source-available example of a project in your preferred > >> coding style? > >> > >> Chef, perhaps? > >> > >> https://github.com/chef/chef/blob/main/lib/chef/application/base.rb > >> https://github.com/chef/chef/blob/main/lib/chef/application/client.rb > > > > Yeah, I think this is probably the closest with regard to indentation > > aside from Eventide, but again, you won't find much indentation there. > > Whatever you find will likely be Vim's default, which I believe is the > > same simple two space indent we are discussing. > > Okay. > > >>> This means that any time we decide to split a method invocation on > >>> multiple lines we use the basic newline after ( style. > >> > >> For "class-level macros" as well? > > > > I found inconsistencies in our codebase, so it is time for us to > > establish a new norm. My guess is that we will land on using parens > > for it. When we do it without parens, it is in the simplified style. > > > > Thank you for your research and work on this, I appreciate it. > > Thank you too. > > We could also discuss cases like > > foo = bar({ > tee: 1, > qux: 2 > }) > > baz([ > 1, > 2, > 3 > ]) > > but those would be an orthogonal feature. And I don't see them much in > the wild, for some reason. The same logic would apply. It doesn't matter how many indent starters there are in a line, the indentation should only increase by one: foo = bar({ tee: 1, qux: 2 }) baz([ 1, 2, 3 ]) Of course, that begs the question what happens if you do this: baz([ 1, 2, 3 ] ) And, I think again, the answer is a social one, rather than a technical one. enh-ruby-mode and vim both do this this: baz([ 1, 2, 3 ] ) I would not even attempt to explain why in this situation they rely on lining up parens, but this is what they do. So, we could either emulate this, or chart our own course. I would have expected it to look like the example I gave with the ] and ) both at the beginning of the line with no indentation. The Vim way looks worse though, which in this instance may be a feature :) Aaron