From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Bozhidar Batsov Newsgroups: gmane.emacs.bugs Subject: bug#16182: Acknowledgement (24.3.50; ruby-mode: Indentation style of multiline literals with hanging open paren inside other parens) Date: Fri, 20 Dec 2013 17:46:10 +0200 Message-ID: <2B4249DE35244273B9602A8B72DB6C08@gmail.com> References: <874n66byoo.fsf@yandex.ru> <52B11F12.4070109@yandex.ru> <490C2BFA3C624DB6AB057CD2AA393D9C@gmail.com> <87txe5v4ol.fsf@yandex.ru> <1E72CA8B046B46A6B320EBB9A71FF8CA@gmail.com> <395424D4599947EBA14047DBA9440BB1@gmail.com> <52B329C1.9050602@yandex.ru> <52B3D3E6.8060409@yandex.ru> <1174B6D834D54E1C83E139525AB3C6C3@gmail.com> <52B4309D.8060502@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="52b46642_6a37288a_1c26" X-Trace: ger.gmane.org 1387554741 24607 80.91.229.3 (20 Dec 2013 15:52:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 20 Dec 2013 15:52:21 +0000 (UTC) Cc: Steve Purcell , 16182@debbugs.gnu.org, Adam Doppelt , Adam Sokolnicki To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Dec 20 16:52:24 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Vu2ND-0007Fp-2B for geb-bug-gnu-emacs@m.gmane.org; Fri, 20 Dec 2013 16:52:23 +0100 Original-Received: from localhost ([::1]:50258 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vu2NC-0003nr-Am for geb-bug-gnu-emacs@m.gmane.org; Fri, 20 Dec 2013 10:52:22 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50340) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vu2IB-0004O6-8R for bug-gnu-emacs@gnu.org; Fri, 20 Dec 2013 10:47:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vu2I3-0000O1-HV for bug-gnu-emacs@gnu.org; Fri, 20 Dec 2013 10:47:11 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:46324) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vu2I3-0000Nu-Cx for bug-gnu-emacs@gnu.org; Fri, 20 Dec 2013 10:47:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Vu2I2-0005mI-Vp for bug-gnu-emacs@gnu.org; Fri, 20 Dec 2013 10:47:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Bozhidar Batsov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 20 Dec 2013 15:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16182 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 16182-submit@debbugs.gnu.org id=B16182.138755437922135 (code B ref 16182); Fri, 20 Dec 2013 15:47:02 +0000 Original-Received: (at 16182) by debbugs.gnu.org; 20 Dec 2013 15:46:19 +0000 Original-Received: from localhost ([127.0.0.1]:60343 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vu2HK-0005kv-SP for submit@debbugs.gnu.org; Fri, 20 Dec 2013 10:46:19 -0500 Original-Received: from mail-ee0-f50.google.com ([74.125.83.50]:36901) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vu2HH-0005kk-NO for 16182@debbugs.gnu.org; Fri, 20 Dec 2013 10:46:16 -0500 Original-Received: by mail-ee0-f50.google.com with SMTP id c41so1127398eek.37 for <16182@debbugs.gnu.org>; Fri, 20 Dec 2013 07:46:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=z2UkRj3C6hrk3QxsaoCw30iBQDtj3+3c4ws3PQmgyNg=; b=lHKzWNGia4px3ZdwpK9VGnzGH9VqWxa/ukMeQApBwn+5fYkY8aoeuAD5o5we3GfEi/ D//lN5oU8wqLrD3DOoc0a9qK43cdGMkndtZ1owDA/28GI7+E4UjGYYiPq63VxL121KSu cNLHvMLpCrDkq6IVAlAYUd4QnUDC6uDVglNZa5kYmPNSZf8x/N3zwiYE57LLjesJ18t6 h6fBwWMKerAQXhJqUO4iBwJiKh7b0MYAbU78I5rR3QwuEcUekKo9emFevnoGFA3kQ5ao LKGuo39cEqgG8csYR9XSrUKt/KNhlqETEX8V7ZCx2Wi/oplX8wQb1Dydh7PWgaRwTsPT B+XQ== X-Received: by 10.14.149.139 with SMTP id x11mr5645505eej.35.1387554374778; Fri, 20 Dec 2013 07:46:14 -0800 (PST) Original-Received: from [192.168.1.28] ([95.87.231.111]) by mx.google.com with ESMTPSA id 4sm19615129eed.14.2013.12.20.07.46.12 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 20 Dec 2013 07:46:13 -0800 (PST) In-Reply-To: <52B4309D.8060502@yandex.ru> X-Mailer: sparrow 1.6.4 (build 1178) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 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.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:82290 Archived-At: --52b46642_6a37288a_1c26 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On =46riday, December 20, 2013 at 1:57 PM, Dmitry Gutov wrote: > On 20.12.2013 11:51, Bozhidar Batsov wrote: > > Just a small nitpick - everything that returns a value is actually an= > > expression, not a statement. > > =20 > =20 > =20 > It can be both (see =22expression statement=22). This way it's not =20 > ambiguous, because I'm really aligning to the statement: the containing= =20 > expression, which follows the bob or an =5Bimplicit=5D semicolon. > =20 > In Rubocop, you've chosen to align to just the parent expression. Maybe= =20 > we should find a realistic example where one would be different from th= e =20 > other. > =20 > =20 I don=E2=80=99t quite understand what you mean. =20 > =20 > > Maybe =60ruby-align-to-expr-keywords=E2=80=99 would be a more appropr= iate name for > > the option. > > =20 > =20 > =20 > I was thinking rather of =60ruby-align-to-statement'. A non-functional = =20 > change that may be easier to pronounce. > =20 > =20 Sounds reasonable. =20 > =20 > > Btw, I noticed this in the indent examples: > > =20 > > zoo > > .lose( > > q, p) > > =20 > > Shouldn=E2=80=99t it be: > > =20 > > zoo > > .lose( > > q, p) > > =20 > =20 > =20 > Maybe, but that's harder to do. Basically, we'd want to keep the =20 > additional indentation when and only when the parent token (.), or any = =20 > one of its siblings (in case of a chained method call) are at indentati= on. > =20 > Checking if the parent is at indentation is easy, but finding its =20 > siblings - not so much. > =20 > =20 I guess this can be ignored for now, since such code is not particularly = common. =20 --52b46642_6a37288a_1c26 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
On =46= riday, December 20, 2013 at 1:57 PM, Dmitry Gutov wrote:
On 20.12.2013 11:51, Bozhidar Ba= tsov wrote:
Just a small nit= pick - everything that returns a value is actually an
expressio= n, not a statement.

It can be= both (see =22expression statement=22). This way it's not
ambi= guous, because I'm really aligning to the statement: the containing
expression, which follows the bob or an =5Bimplicit=5D semicolon.

In Rubocop, you've chosen to align to just the pa= rent expression. Maybe
we should find a realistic example wher= e one would be different from the
other.
I don=E2=80=99t quit= e understand what you mean. 

Maybe =60ruby-align-to-expr-keywords=E2=80=99 would be a = more appropriate name for
the option.
<= div>
I was thinking rather of =60ruby-align-to-statement'. = A non-functional
change that may be easier to pronounce.
=
Soun= ds reasonable. 

<= div>Btw, I noticed this in the indent examples:

= zoo
.lose(
q, p)

Shoul= dn=E2=80=99t it be:

zoo
.lose(
q, p)

Maybe, but t= hat's harder to do. Basically, we'd want to keep the
additiona= l indentation when and only when the parent token (.), or any
= one of its siblings (in case of a chained method call) are at indentation= .

Checking if the parent is at indentation is ea= sy, but finding its
siblings - not so much.
<= /span> =20 =20 =20 =20
=20
I guess this can be i= gnored for now, since such code is not particularly common.
--52b46642_6a37288a_1c26--