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: Fri, 23 Dec 2022 19:17:11 -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="17902"; 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 Sat Dec 24 01:18:18 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 1p8sEz-0004Sw-Qk for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 24 Dec 2022 01:18:17 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p8sEo-00086t-92; Fri, 23 Dec 2022 19:18: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 1p8sEm-00086i-5K for bug-gnu-emacs@gnu.org; Fri, 23 Dec 2022 19:18:04 -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 1p8sEk-00055H-P2 for bug-gnu-emacs@gnu.org; Fri, 23 Dec 2022 19:18:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p8sEk-000400-3S for bug-gnu-emacs@gnu.org; Fri, 23 Dec 2022 19:18:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Aaron Jensen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 24 Dec 2022 00:18:02 +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.167184105215340 (code B ref 60186); Sat, 24 Dec 2022 00:18:02 +0000 Original-Received: (at 60186) by debbugs.gnu.org; 24 Dec 2022 00:17:32 +0000 Original-Received: from localhost ([127.0.0.1]:39641 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p8sEG-0003zM-1U for submit@debbugs.gnu.org; Fri, 23 Dec 2022 19:17:32 -0500 Original-Received: from mail-pg1-f173.google.com ([209.85.215.173]:42676) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p8sED-0003zE-Rw for 60186@debbugs.gnu.org; Fri, 23 Dec 2022 19:17:30 -0500 Original-Received: by mail-pg1-f173.google.com with SMTP id v62so1181819pgd.9 for <60186@debbugs.gnu.org>; Fri, 23 Dec 2022 16:17:29 -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=Gf2SHRfmdAGn1ef+ac6BCiBWzNfgJG2LY76u78OdtDQ=; b=D232sYX9YrDKJxgv7M2HBzWVjGgJsvwBvswZi3OWE8tzlxzfgEW/pDQ/ynfyDjJ/wz /PNcB2PA0AwIDNG2JyEaL0loNXPVAEy/4C50Uws4d339A8UXbRt8NadLpTm+w5PLCZFI 612nlTjSw5ZpxvyprqCS0Pz31tXOFs0yldTfu2UeGBS2zTD1D/SJhiqUzl3JeIwvPH3t pJPucYRy/DstUtC441+3F5oDULlAaCYIstC7cRePqn+MLDV9r5zVe9bYrZyxp4kjTFpL UZFYG5YtRATL55qe0vffoFSncLCBEK7HafyWlH837IMhUzuf8NUoKyND/kP9mkwnE921 4Z6w== 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=Gf2SHRfmdAGn1ef+ac6BCiBWzNfgJG2LY76u78OdtDQ=; b=aG9+Fr+u4oajCaiLv+hVqCL0InhYhzMIeStTt92Sd3fd7HcAUEfttGAW2D80iWV29d LcRDvGNDZxx5QGFEAdMMzSOMmzWEPDtIRQobtCKC8PTUfGQ6FReZtvdk6zWvZIdDRYYF Fp8Mxscqi+VHG9sEa6Xu5ku3N4Y3GWHbqCEz7AS/ucsfZS+RIJh7pSLUA2D1/OEcEjIi Jyshth8qBgMvCCW8oGvQNl0vVGENAvDecQMPJq6p8VmnTa/v3MmQxS2x3dpoFvlRKZ+k bSZNDjz4AVzmbNav3AyaLW4+jW/zEXDY71RNGr1LwnGICUUAn3w8PxYvKU52d6TsR4sm M0jg== X-Gm-Message-State: AFqh2kpw5mID0JIXA7XFFiFhBfKrEoNCSJcTK5fJSFvzQN7SVOTTfvI4 k3FW9jKi+aFMgLR4KBg0fCcJlp5tcH6cvScCOXA= X-Google-Smtp-Source: AMrXdXvR3RWPU5GicgvF8M1cHmVcuuV7lDfp7OYnFC/paCnDL6if+7l6oRoPY4khy9oJhj0SFDLdDPZEJ2tAO7XlnMA= X-Received: by 2002:a63:4d12:0:b0:478:a6de:4d1b with SMTP id a18-20020a634d12000000b00478a6de4d1bmr497068pgb.95.1671841042894; Fri, 23 Dec 2022 16:17:22 -0800 (PST) In-Reply-To: <902440c7-706a-20e1-55af-4e12e8cdda2c@yandex.ru> 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:251754 Archived-At: 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 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 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). > I checked out some popular projects out there. Rails' style is > inconsistent, with class-level parenless calls lined up vertically and > the rare use of them inside methods seem to go the "simplified" route. > I'm not sure if that's intentional, or whether it's just written by > different people. > > Redmine mixes styles, but mostly on the side of lining up. > > Spree lines up and overall seems to vindicate the default "lispy" > indentation style, e.g. here: > > https://github.com/spree/spree/blob/main/core/app/models/spree/zone.rb > https://github.com/spree/spree/blob/main/core/app/models/spree/tax_rate.rb > > 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. > 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. > > 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. Aaron