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: Mon, 19 Dec 2022 23:48:39 -0500 Message-ID: References: <4e44df18-207c-c7ca-0588-7285f3008dfb@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="27058"; 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 Tue Dec 20 05:49:14 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 1p7UZ0-0006oL-AI for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 20 Dec 2022 05:49:14 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p7UYq-00067E-Et; Mon, 19 Dec 2022 23:49:04 -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 1p7UYo-000675-Ro for bug-gnu-emacs@gnu.org; Mon, 19 Dec 2022 23:49:02 -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 1p7UYo-0006OP-KV for bug-gnu-emacs@gnu.org; Mon, 19 Dec 2022 23:49:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p7UYo-0005rB-C9 for bug-gnu-emacs@gnu.org; Mon, 19 Dec 2022 23:49: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: Tue, 20 Dec 2022 04:49: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.167151173822507 (code B ref 60186); Tue, 20 Dec 2022 04:49:02 +0000 Original-Received: (at 60186) by debbugs.gnu.org; 20 Dec 2022 04:48:58 +0000 Original-Received: from localhost ([127.0.0.1]:42366 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p7UYk-0005qx-4N for submit@debbugs.gnu.org; Mon, 19 Dec 2022 23:48:58 -0500 Original-Received: from mail-pj1-f45.google.com ([209.85.216.45]:45843) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p7UYi-0005qr-9K for 60186@debbugs.gnu.org; Mon, 19 Dec 2022 23:48:57 -0500 Original-Received: by mail-pj1-f45.google.com with SMTP id v13-20020a17090a6b0d00b00219c3be9830so10933333pjj.4 for <60186@debbugs.gnu.org>; Mon, 19 Dec 2022 20:48:56 -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=A19oJxjapqoa/nv9NeUz/dS8+G5CUdFOgCXWlp0vU+A=; b=lqVMAmeCeZgJTIFnh4A9dhwJZgEAxxc6Kz4Zc6VKfd/2IlS+nizoJOv7FGfbsbEjCj a9prPFPPtn4a0TuaEs29WeywNkNwVTL2u6PRT5Gn8n+1L+uApldN7PUyo9sBeDxi8vF9 lADETQLxtI77+wtomLTqTxEhVk60MDCNmkckcGmpb+yY0l+gyI0aZBNIy/VkA1473NqC +t9DetAYsySsHu1u6a/J0uTvTD8poKrF3yuwCZiiX4dgq3NTpErSU4SvuESWliyPZZNA JWPSNukeoIaY5vCFpbLckLqbSUUF+jrveS0glhDmrk42stGZiz7pomEwT4yO6O4PwSwi u/Zw== 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=A19oJxjapqoa/nv9NeUz/dS8+G5CUdFOgCXWlp0vU+A=; b=jk+Iy0MPwneDpUZdgnjVnGHyr0PSVjlsx1mwg/QHdBOEpXX3sYBDYIjjDb1XE+FAJB 3VqcQTKpanneaTVdoAJRkPrr5EvmUUJzFB03Awe1z8s7KLu0tz00mC4jRNzzCoonY2MG ZnbRcjJZz+zbV/S58ApT05kGiR9i0XdQAOgPMCkKSj5itH7iMqG4JHGMEBriulQ9hbqY B0YKNR700PneLtJvkrlCJo86Fuova2wIt6TvX3dk6emrQb018QEWQ+JTGHWCM67+v17S 2AIK7VVDOG5bPfG1bjLXy98IVssWtKeuDDB9m+qRss24KzChzd7aw3nQQb+eZT9VkT4C J8ag== X-Gm-Message-State: ANoB5pmdkXOhY/rvO9zfPPIkxx2UVbaQ6M/v5+69pNJTj6IX8rMfUkKA d2FVOOJ4GyoZGB8a6FxtWDOWVjUQ7wIPXMNMqnwqM6AQQGGZgw== X-Google-Smtp-Source: AA0mqf5u/Od3IBeMRzXW8CnOBM8DwKu6CM64/nyCfjcXM85GdbxtCjt/4m41rGsR3M9ECm3ztrxT++wpS7fyL5AM7N4= X-Received: by 2002:a17:902:7689:b0:189:b6cf:850d with SMTP id m9-20020a170902768900b00189b6cf850dmr32731280pll.30.1671511730234; Mon, 19 Dec 2022 20:48:50 -0800 (PST) In-Reply-To: <4e44df18-207c-c7ca-0588-7285f3008dfb@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:251493 Archived-At: On Mon, Dec 19, 2022 at 9:12 PM Dmitry Gutov wrote: > > On 19/12/2022 04:54, Aaron Jensen wrote: > > > > Follow-up to bug#60110 > > Thanks! > > > I prefer rather simplictic indentation for Ruby (and this appears to be > > pretty common from codebases I've seen). Essentially, the rule is: If an > > expression continues on another line, indent it once. > > FWIW, this feels a little wasteful -- working to emulate the editors > which don't have much of a grammar definition, so they mostly line up > things to the beginning of the previous line (plus maybe the indentation > offset). > > But I guess that can make some experience better when working in teams. The implication here is that the current indentation rules are somehow objectively better. I'd argue the opposite, that they have usability issues. :) In all seriousness though, > > Current: > > > > some_variable = some_object. > > some_method > > > > Desired: > > > > some_variable = some_object. > > some_method This one isn't quite right, maybe there was an email formatting issue. I'm expecting some_method to be indented by 1 level, for me it's 2: some_variable = some_object. some_method > > > > Current: > > > > some_variable = some_number + some_other_number * > > some_third_number + some_fourth_number - > > some_fifth_number > > > > Desired: > > > > some_variable = some_number + some_other_number * > > some_third_number + some_fourth_number - > > some_fifth_number This looks good. > > This was easier to change than I expected, so here's some patch > attached. It's very WIP -- before moving it to release some > reorganization of indentation rules is in order, to be able to put the > new option in just one place, and to streamline how indentation after > "." works. > > This won't make it into 29.1, but we can put ruby-mode in ELPA after. > > > I don't know if this last one is related or not, but it follows the same > > rule plus the rule about blocks. Everything about the continuation of > > the expression is indented once. The contents of the block are indented > > once more. The end should line up with the line that opened the block. > > > > Current: > > > > some_variable = some_array. > > map do |x| > > x + 1 > > end > > > > Desired: > > > > some_variable = some_array. > > map do |x| > > x + 1 > > end > > This will take some more work too. Not in the least because the > "Desired" forms looks illogical (at least in the context of SMIE): we're > already "escaping" the current syntax node to line the indentation of > the block to the beginning of the statement (which makes sense, at least > from the ergonomics POV), so why would the line break matter? Do you mean why are these different? some_variable = some_array. map do |x| x + 1 end vs some_variable = some_array.map do |x| x + 1 end It's because the end is lined up with the line opened the block/increased indentation. In the first example, the indented map line is the beginning and on the second, it's the assignment. > > Take more complex cases. How much indentation will the block have after > some heterogeneous continuations? Is this right? > > some_variable = 4 + > some_array. > reduce do |acc, x| > acc + x > end No, there is nothing that would cause reduce to be further indented. It should be this: some_variable = 4 + some_array. reduce do |acc, x| acc + x end > What if the continuations are all after the same operator? > > some_variable = 4 + > some_var + > some_array.reduce do |acc, x| > acc + x > end > > some_variable = some_var. > some_method. > map do |x| > x + 1 > end Yes, these look right. Thanks, Aaron