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: Tue, 20 Dec 2022 15:05:05 -0500 Message-ID: References: <4e44df18-207c-c7ca-0588-7285f3008dfb@yandex.ru> <358bbd65-9375-04c8-f0a2-24a4383f142e@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="35130"; 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 21:06:17 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 1p7isT-0008pG-8p for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 20 Dec 2022 21:06:17 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p7isH-00035u-HI; Tue, 20 Dec 2022 15:06:05 -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 1p7isF-00033k-31 for bug-gnu-emacs@gnu.org; Tue, 20 Dec 2022 15:06: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 1p7isE-0001iU-QK for bug-gnu-emacs@gnu.org; Tue, 20 Dec 2022 15:06:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p7isE-0007fU-96 for bug-gnu-emacs@gnu.org; Tue, 20 Dec 2022 15:06: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 20:06: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.167156672529465 (code B ref 60186); Tue, 20 Dec 2022 20:06:02 +0000 Original-Received: (at 60186) by debbugs.gnu.org; 20 Dec 2022 20:05:25 +0000 Original-Received: from localhost ([127.0.0.1]:46911 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p7irc-0007fB-PO for submit@debbugs.gnu.org; Tue, 20 Dec 2022 15:05:25 -0500 Original-Received: from mail-pj1-f42.google.com ([209.85.216.42]:54793) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p7ira-0007f3-Ro for 60186@debbugs.gnu.org; Tue, 20 Dec 2022 15:05:23 -0500 Original-Received: by mail-pj1-f42.google.com with SMTP id o12so13520038pjo.4 for <60186@debbugs.gnu.org>; Tue, 20 Dec 2022 12:05:22 -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=Cr8ytWr+l1O0zrEwkFYPNk93TVVZoOVBf8lsy/mOLXk=; b=TcYensJrrH46GxHqMJMUENlvogowdt2wQZNEmfbWXmJjJ62+4aci0c2a/VHlpwKX45 B4UxRAW5EVolxsphmhWTj/m/Rh7KM6wkUBzzW51QHN+kV2j5AhzCVAGncF+ZRxxOQb4H YCBrf4V060QCKp13CHmUlIPxujVwBadwtuMGKKMl61qdAtTt9MRs2kMxgST6GVzfiaOK F6D2DXHNitjeKqT6njwmFucefrYhsHbUTWkYlr++Cj8OMjAFhDVYjDB90lzuRuSgcmjM GPGI9iiQg6XVhmG5I9uaGC8itmRwiYmzE89I1mVg58E398zfNNBVlNG/FiPJvOj19RZh jrcA== 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=Cr8ytWr+l1O0zrEwkFYPNk93TVVZoOVBf8lsy/mOLXk=; b=zrhqvvmBfPPg8Nw7WEmpPA6L6ZxSpmE/Ror9c4DX1lz2pdc0nCyc+uJ8NH+tVG5mND cIasxTVJ3XtVYOIEPzWemyN0RqiZ7tdvrDFKI8Tq1JzH5KAzajLoZq15iXicHsi2NMSL 6/Rp/8Ix+Mtog5qROh1aQmuPqIz1le64DRIbUgnf+YWRtLBGJ83DiN5SfJClE5bvKVI7 KZg1YdS9np/zm41Azndn8Vr9G3SeB9KiQ+PBxjKFPA88YkspaENMZ1CnA2Fyv9IcHLoQ en1gjqTzMy41X2h/+BwA7Cy8orfuSbeIW+e8Te6O7zSLVYhuf18KABQ9dnBPVHnCTUic eOhw== X-Gm-Message-State: AFqh2kqhP/04PAbI4IKV11mNBoaL342foDNNu7RzzoKDu1HqvHrSJNBQ 0YPNKB1TsflaaaiR6wyOkoeJl3MEAoHc00jzm70= X-Google-Smtp-Source: AMrXdXtToq1g1+pQTwDfg04GSbL4oarhCD7MgN7qNkLsHHbh7ERNzrChtS3BSQJs2JSGp2MAQt2cUrfgOQRWsOy0iWw= X-Received: by 2002:a17:90a:5294:b0:223:f336:1519 with SMTP id w20-20020a17090a529400b00223f3361519mr223615pjh.198.1671566716779; Tue, 20 Dec 2022 12:05:16 -0800 (PST) In-Reply-To: <358bbd65-9375-04c8-f0a2-24a4383f142e@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:251542 Archived-At: On Tue, Dec 20, 2022 at 11:19 AM Dmitry Gutov wrote: > > On 20/12/2022 06:48, Aaron Jensen wrote: > > > 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 > > Yes, that's also the "needs more work" part. > some_variable = some_number + some_other_number * > some_third_number + > some_fourth_number - > some_fifth_number Yeah, with this I'd probably be trying to give a name to some of the things (what is the name of the product there?) I don't think I've ever seen code like that in practice to be honest. > > >>> > >>> 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. > > The funny thing is this case looked more difficult originally. > > >> 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. > > One might ask why it's lined up to 'map' only after it's moved to the > next line, but not in the first example. It's never lined up to map, I don't think that's the right way to think about it. It's lined up to indent level 1. It isn't until after the `end' that the indent level returns to 0. Line continuation (mid-expression): +1 indent level Block opening (mid-block): +1 indent level Paren opening (mid-arguments/params): +1 indent level And all the closing/endings: -1 indent level Only one indent level can be added per line, so all that matters is where the line ends. In short, there are a set of expressions that require indentation if they span multiple lines: expression-start expression-middle expression-end I haven't tried the patch yet, but I'll give it a shot. Thank you, Aaron > > Anyway, the important part is to choose an unambiguous algorithm, even > if it uses its own logic. > > >> 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 > > Okay, so there should be two basic cases: > > - Indent to the beginning of the statement, > - If there was a line continuation (no matter how many), indent 1 extra > level? > > And maybe something related to parentheses, if used.