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 19:38:14 -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> <8d554fc2-7da5-cfe1-c865-023d56d222e3@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="24210"; 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 Wed Dec 28 01:39:28 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 1pAKTg-00069V-0H for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 28 Dec 2022 01:39:28 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pAKTL-0005wP-DL; Tue, 27 Dec 2022 19:39:07 -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 1pAKTH-0005w4-6L for bug-gnu-emacs@gnu.org; Tue, 27 Dec 2022 19:39: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 1pAKTG-00029P-Oj for bug-gnu-emacs@gnu.org; Tue, 27 Dec 2022 19:39:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pAKTG-0004OR-Bp for bug-gnu-emacs@gnu.org; Tue, 27 Dec 2022 19:39: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: Wed, 28 Dec 2022 00:39: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.167218791316832 (code B ref 60186); Wed, 28 Dec 2022 00:39:02 +0000 Original-Received: (at 60186) by debbugs.gnu.org; 28 Dec 2022 00:38:33 +0000 Original-Received: from localhost ([127.0.0.1]:56788 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pAKSn-0004NQ-7z for submit@debbugs.gnu.org; Tue, 27 Dec 2022 19:38:33 -0500 Original-Received: from mail-pg1-f175.google.com ([209.85.215.175]:46015) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pAKSl-0004N6-Dq for 60186@debbugs.gnu.org; Tue, 27 Dec 2022 19:38:32 -0500 Original-Received: by mail-pg1-f175.google.com with SMTP id r18so9673022pgr.12 for <60186@debbugs.gnu.org>; Tue, 27 Dec 2022 16:38:31 -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=NP7gxj4mFDsK/F3OCAptdWLri+Igz1WqBepbta/tPOM=; b=a+Cs888pHpuBPyXshXRM/lM1Pp/pfTHjB73jdSfpc9iywwy6Q3H7sidCkpidPgW9ox 89+QMv/KtvVm8GNPEMuYLvlxhSUnIQ+q1+Q2o/E72RsK0nEeNePQmxI06CAQqpUINO2q 65SD7evVdC1JWa8Y13Yk7e/cDEtE5ai8jPnipd1e43V32GA9vOhGjAdwC35tYD6d1wbe L4ud1PU+otX+zhtV3U7lbkGoabAZcp9pfjOtiZAHhI0J4qr7h82PCO58IyUe1M0GOmle mHsH6udiKWq0aht/evL5UFFl2MjgLQHo3swMgNnNoAR88guK8bxA9QfrPGshRgQzhgxz YdDg== 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=NP7gxj4mFDsK/F3OCAptdWLri+Igz1WqBepbta/tPOM=; b=YvBHIruI258XUUxFeku4AVs/vNK0OoMHxKTOTC5pHbjsn8ALGeaZMSIyRHSLeKUpRZ 9TVst+ranFEC9e631qOkapa8DuEbxyIbTIgJ7CHXX1ImcvkBTiqlzAWUfX1EgAC8Hk6v gHO8Rzbm3Fl2v36EsHbt0TStamNeJJJ7GTKlwTPfSXa+DrG+NK8IuBwGNZzOzylQb+wC /wj2+ecTj3bPAfWs+c1ha7A/P1TxxpVm+SZUQMl/zHFF4K0RcOKPpilcC7HGySeoY29j +/rW/SojVxpKvZbutkaOvTGI+9e1BHFwmZrJid0bl3lrJZAcnv3kTq8Vksc9FplUnzoY /GLw== X-Gm-Message-State: AFqh2kqSX54pWSEMkkqNi63lhKXS1ujbt8zV3plv1s6NhH0ebZJMxs5y iPlKYPXkea43fEq8w9rq0YQOV7SURj3zU5qECjw= X-Google-Smtp-Source: AMrXdXu/sTYXCnBeBMb8661iHEesP2NUrnN87opYIGRaB5fEh7bJBklGWRiSlEBaP2hzUW5WWKbzn86QMZt6rraygBM= X-Received: by 2002:a65:4c81:0:b0:486:f3bf:822e with SMTP id m1-20020a654c81000000b00486f3bf822emr1360848pgt.482.1672187905211; Tue, 27 Dec 2022 16:38:25 -0800 (PST) In-Reply-To: <8d554fc2-7da5-cfe1-c865-023d56d222e3@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:251972 Archived-At: On Tue, Dec 27, 2022 at 6:04 PM Dmitry Gutov wrote: > > On 27/12/2022 18:34, Aaron Jensen wrote: > > >>> 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. > > That's true. > > But it seems we've rejected most of each other's suggestions by now. > > >>> 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. > > Right. If we consider "." as something distinct, it could use a separate > option. Or not. But it's trivial to separate. > > >> "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. > > Concur. > > > 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. > > IDK, there might be different connotations, e.g. it always grows (though > slowly). > > > 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. > > "More" context-aware, one could say. Or less. But that's the same as > "simpler". > > I suppose we could call it structural..? The current behavior, that is. > As in > https://github.com/yairchu/awesome-structure-editors#structural-code-editor-projects. > > Or here's a step back: looking at how the two other user options I named > previously were ruby-method-params-indent and ruby-block-indent, the > latest might as well be called ruby-operator-indent, or > ruby-operator-indent and ruby-method-call-indent. > > I wasn't too crazy about those names originally, but the approach is > very extensible with styles by adding new symbols as possible values. This may end up being the right direction. If the values are symbols you can use things that are relative to one another like "simple". There could be a benefit to all of these having a "simple" option. What would it mean if it were nil? What's the current behavior called? It may be that if we only intend to support two indentation schemes we just have default and simplified as you suggested and then we can use boolean values. I don't know how Emacs-like this is, but what if there were one variable like `ruby-indent-simple` that could either be `t` or a list of things to indent simply? Aaron