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, 27 Dec 2022 11:34:26 -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> <688159e9-f6bc-f233-08c4-9834bc00c455@yandex.ru> <74f977f6-d9ba-04bd-fba0-0dce4729cf0d@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="34183"; 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 27 17:35:41 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 1pACvV-0008jA-GL for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 27 Dec 2022 17:35:41 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pACv2-00080e-AV; Tue, 27 Dec 2022 11:35:12 -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 1pACut-0007wj-ED for bug-gnu-emacs@gnu.org; Tue, 27 Dec 2022 11:35:05 -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 1pACus-0006NZ-JG for bug-gnu-emacs@gnu.org; Tue, 27 Dec 2022 11:35:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pACur-0006PU-Qg for bug-gnu-emacs@gnu.org; Tue, 27 Dec 2022 11:35: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: Tue, 27 Dec 2022 16:35: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.167215888624614 (code B ref 60186); Tue, 27 Dec 2022 16:35:01 +0000 Original-Received: (at 60186) by debbugs.gnu.org; 27 Dec 2022 16:34:46 +0000 Original-Received: from localhost ([127.0.0.1]:56377 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pACub-0006Ow-TS for submit@debbugs.gnu.org; Tue, 27 Dec 2022 11:34:46 -0500 Original-Received: from mail-pf1-f171.google.com ([209.85.210.171]:41496) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pACuZ-0006Oi-Vb for 60186@debbugs.gnu.org; Tue, 27 Dec 2022 11:34:44 -0500 Original-Received: by mail-pf1-f171.google.com with SMTP id k137so4377499pfd.8 for <60186@debbugs.gnu.org>; Tue, 27 Dec 2022 08:34:43 -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=DFNRAWEg4PjUuXptyUpA9UsGELdwFy77BmPm/lkyE70=; b=f4xOdv/qsnRToqKXWFZn9Tm21OCfgZbdtnURnV5DAHocGLA3vwqHqCj7P7xybGiKoQ l/Say/8qQh9OGp+30CAZaqFqpyM2ICcK7rNt530aOk6X50CrEPRgfwDRH3Akv+b7MncP 3o8uFNJoLQPlNF6GX0l3rKSPB8JIv0aM1uiF7K8d6uDyBjSzoZNzmbb0dNXjISbZRS8g qCPr7hlV9djNeNbIw0Q3oiicDla52Sya+sfx7oLIT1wcpVITaSzHeIwi1IVuXioK/s4m JhheZ0TtmIMfQBkkcCm2lxdGlyArklYA8s90l4/GZOfLdLQZlFImWO5btJGY+qdvJXde cw4Q== 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=DFNRAWEg4PjUuXptyUpA9UsGELdwFy77BmPm/lkyE70=; b=dPmoZ2iTpgzsBs7RwvQD/ICnyKQ6hXr/79F3N6ikFg3w92lio7VFvO2LCN/R5oaMqD 9IOFrL69FWqT00TlZb1gdnv7ZCT8j8GznL0rxRLcCUNzxwBGYbEcOQxF7gGRg8AMkJNk adGkWeH84LpiOH/ndaVqR3Pnx8SgVyPm211rm/m9C9X59PgAoM3ZL9gpdcvSt8vECF6d Fy88Ksd7OdSwB+2hu6e1l/xS4A3VjshUlmJZ5wNutDLH5u5ktWFlkFNudXoVPTcLIGnC cdIeYh7cyY4SbYdI53cxZDtxa4qXcSXwlt1XSr0foF9IsJ93DbggNuGkQwX8hgg1jJqc IbPA== X-Gm-Message-State: AFqh2kogvYfHB77sFNfiHm1VaMHs++2TrmGmdHntqaGZ3XbAIZtak9ci L9KbKZvwtOJy1PP1fMifC9CPru+jiHCFLgvwC0M= X-Google-Smtp-Source: AMrXdXvjD7HBki63nTVuBDWej/teBKpv/9ly+vcdFad3+tuGoKeVNCWz3xc+gkEzRFhurm1JMj7tVsdn+4Q6u9YUXZM= X-Received: by 2002:aa7:8653:0:b0:578:5df5:9abe with SMTP id a19-20020aa78653000000b005785df59abemr1437291pfo.33.1672158877948; Tue, 27 Dec 2022 08:34:37 -0800 (PST) In-Reply-To: <74f977f6-d9ba-04bd-fba0-0dce4729cf0d@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:251960 Archived-At: On Tue, Dec 27, 2022 at 10:56 AM Dmitry Gutov wrote: > > On 27/12/2022 03:47, Aaron Jensen wrote: > > On Mon, Dec 26, 2022 at 8:28 PM Dmitry Gutov wrote: > >> > >> On 25/12/2022 02:14, Aaron Jensen wrote: > >>> (setq ruby-indent-simplified t > >> > >> BTW, do you have any opinion on the name? Perhaps something more > >> semantic would be easier to discover. > >> > >> A recent tree-sitter thread brought up sh-indent-after-continuation. > >> It's not a direct counterpart, though, and the examples only look > >> remotely similar. > >> > >> Call ours ruby-indent-continuations-simplified, maybe? Now that we seem > >> to have reduced its scope to expression continuations across newlines. > >> > >> Hopefully it won't be confused with Kernel#callcc. > > > > Simple is what it is in comparison to something more complex. > > Just 1 indent vs arbitrary number of indents depending on operator > priority/ast nesting. Seems like "simpler" is appropriate. Right, but that was my point. The name doesn't stand on its own. It only stands relative to some other more complex indentation scheme. If we can find a name that stands on its own, I think that would be better. > > All > > indentations are pretty much about line continuation in one way or > > another. > > Okay, how about ruby-indent-operator-continuation? > > Or ruby-indent-binary-op-continuation. Which would include all binary > operators and method calls. *shrug* We could also split off the method > call indentation to a separate option too. Right, maybe it makes sense to consider one of two directions: 1. A single option to enable this "simple" indentation mode, i.e. ruby-indent-alignment: line/statement/start/beginning vs. sibling/end 2. Split each different rule into its own option and name them according to the specific circumstance the rule covers. I still don't know what the options would be. That said, when you say method calls, you mean the '.' operator, yes? I see what you're getting at with this naming and I think it's probably cohesive enough to be one option per #2 above. > > What is it on its own? I'm not sure. > > > > Some food for thought: > > > > Unaligned > > That might be a good adjective (if we take it to mean, not aligned to > the closest parent AST node), but something else to narrow down the > scope is needed in the name. ruby-operator-unaligned-indent? > > ruby-operator-shallow-indent? > > > Beginning of line aligned > > Beginning of statement, I guess? Yeah, that would be better than line > > Standard > > "Standard" is a point of view. ;-) Indeed... there is also https://github.com/testdouble/standard but I think it's a bit of a land grab to call it standard and I've never really looked at it. I put incremental in the last list since I was trying to get at the fact that the indentation increases by one increment at a time. Is there something about it being that vs it context-aware? Obviously all indentation is context aware, so I'm not sure that that's the right direction. Aaron