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#60321: 29.0.60; ruby-mode indentation of hash or array as first arg in multiline method call Date: Mon, 26 Dec 2022 20:38:03 -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> <1191195d-1528-dc2a-64e0-15426e4b5608@yandex.ru> <75342f40-d576-e1c6-3d63-692b80e78bfe@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="15317"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 60321@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 02:39:16 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 1p9yvz-0003tf-T0 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 27 Dec 2022 02:39:15 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p9yvn-0003wA-MG; Mon, 26 Dec 2022 20:39:03 -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 1p9yvm-0003vz-KP for bug-gnu-emacs@gnu.org; Mon, 26 Dec 2022 20:39: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 1p9yvm-0000NE-CT for bug-gnu-emacs@gnu.org; Mon, 26 Dec 2022 20:39:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p9yvl-0000eD-Q9 for bug-gnu-emacs@gnu.org; Mon, 26 Dec 2022 20:39: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 01:39:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 60321 X-GNU-PR-Package: emacs Original-Received: via spool by 60321-submit@debbugs.gnu.org id=B60321.16721051032440 (code B ref 60321); Tue, 27 Dec 2022 01:39:01 +0000 Original-Received: (at 60321) by debbugs.gnu.org; 27 Dec 2022 01:38:23 +0000 Original-Received: from localhost ([127.0.0.1]:54401 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p9yv8-0000dI-Uc for submit@debbugs.gnu.org; Mon, 26 Dec 2022 20:38:23 -0500 Original-Received: from mail-pf1-f180.google.com ([209.85.210.180]:42801) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p9yv6-0000d4-Ru for 60321@debbugs.gnu.org; Mon, 26 Dec 2022 20:38:21 -0500 Original-Received: by mail-pf1-f180.google.com with SMTP id 65so8038373pfx.9 for <60321@debbugs.gnu.org>; Mon, 26 Dec 2022 17:38:20 -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=gzqil5gDqWHnl76ZxfppUAYj0jRao6Z1FEDcEOZdqXE=; b=CRTOgt+p6ufFHiO5KXbelNge+PEpYwbKDVWN+xi9Z+WZcyjkbFYlL/GdIkwq1UuuSx +hCxWy+q9ZV2/NuxNSFuZnNPFiP9eI3CXP+IcN4u2xDRmVPX4URQDxE9wz8tf4gAHc8I /u0Hzz3liomMev+jvE3n0msR4FLIFvN+bgDLnEZQNBKoggeTlHXCetTeiYr/RrJSyUAf w4kEfU0P73wNQSWNSMxGidmcgyC1JtEX1uwGQJ4daPI9SHbMSqX1SYelZEx7BGLW0b+E fHD3x8cqOTde5Oc8eNhezNJ/V+5+ctvUl4YxRl5H2s71aksgpK2AT6Cso7pIh+QcOEe0 Z3/A== 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=gzqil5gDqWHnl76ZxfppUAYj0jRao6Z1FEDcEOZdqXE=; b=BNYH2wwK+KvW1TQVEVzXpSxkVC6CG3aGr5eicjEsb04nEVTKlNuZ+KdVfL/hqfvPCt vp9JCSSYV3sN3e6wl33VxFxcYpbd4ee/4Zop0f/7AfcobwaTJ8Kg1rq/V/KnWrHrI33R D0lid0jRGgiGEn07h3w0isZ6th/+foM0Gz5sNrh3XkGTki2oNdmPu6Q3u/WgED82CWNz Ws+K8gO8k4gkEtlCqb6KhCruNSCPBlx8uA/31SBK2hVApZltom/UytaCOklVDLvb+aIF TCMW/lyLxPvkKiwP2ohLUA0SyNg6Fmhm70xtMgq2oy54GRx7M8908NXgnbwYfwQKTBPZ +mYw== X-Gm-Message-State: AFqh2kphPLuokDpiUrMixe1jSMwx5aJ2eOj+sb1c+PJOVg7m/i9a95G4 LBBNBahiqH/ZsmhxoZ3XMLUbd7lLRJu5tX5mxzQ= X-Google-Smtp-Source: AMrXdXvaaPKgXlUEaQFwpXAdleaYEqFd8DWnEdJrKkrv5Aqvveh0gS/Ee8QTjvn34KoNesr/igvYt9TsuLiZZixd4Bg= X-Received: by 2002:a62:388d:0:b0:576:9786:94c2 with SMTP id f135-20020a62388d000000b00576978694c2mr1267302pfa.26.1672105094553; Mon, 26 Dec 2022 17:38:14 -0800 (PST) In-Reply-To: <75342f40-d576-e1c6-3d63-692b80e78bfe@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:251929 Archived-At: On Mon, Dec 26, 2022 at 8:16 PM Dmitry Gutov wrote: > > Vim's choice looks saner to my eye. Probably comes down to the choice of > indentation algorithm, though. Agreed, though it's hard to pick which is more sane when all the options start with insanity. > > If I had to type it as above, I would probably indent it like this: > > > > and_in_a_method_call({ > > no: :difference > > }, > > foo, > > bar) > > > > But I can't imagine that would be easy to implement at all, so I > > wouldn't bother. > > The indentation logic itself might be not that difficult to write, but > the fact that the expression will have to be reindented as soon as the > method call grows a second argument (after the user types the comma?), > makes it a hard sell usability-wise. Right, I think that's just more of the same thing... We are looking at ways of writing code that are out of the realm of reason. It's a challenge to define behavior when the behavior could very well be undefined. But, if we must define it, then what are our guiding principles? Not having to reindent preceding lines when adding a new line may be a very reasonable one. In that case, the only two options I could think of would be: and_in_a_method_call({ no: :difference }, foo, bar) or and_in_a_method_call({ no: :difference }, foo, bar) The difference being if we decide to dedent upon the last closing indent-requiring-token or the first. I think a reasonable rule of thumb for a human might be: "If you open N indents on one line, you must close N indents on one line". Any time you stray away from this, behavior becomes... not ideal. Aaron