GNU bug report logs - #16182
24.3.50; ruby-mode: Indentation style of multiline literals with hanging open paren inside other parens

Previous Next

Full log

View this message in rfc822 format

From: Bozhidar Batsov <bozhidar <at> batsov.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Steve Purcell <steve <at> sanityinc.com>, 16182 <at> debbugs.gnu.org, Adam Doppelt <amd <at> gurge.com>, Adam Sokolnicki <adam.sokolnicki <at> gmail.com>
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 part 1 (text/plain, inline)]

On Friday, 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.
> >  
>  
>  
> It can be both (see "expression statement"). This way it's not  
> ambiguous, because I'm really aligning to the statement: the containing  
> expression, which follows the bob or an [implicit] semicolon.
>  
> In Rubocop, you've chosen to align to just the parent expression. Maybe  
> we should find a realistic example where one would be different from the  
> other.
>  
>  

I don’t quite understand what you mean.  
>  
> > Maybe `ruby-align-to-expr-keywords’ would be a more appropriate name for
> > the option.
> >  
>  
>  
> I was thinking rather of `ruby-align-to-statement'. A non-functional  
> change that may be easier to pronounce.
>  
>  

Sounds reasonable.  
>  
> > Btw, I noticed this in the indent examples:
> >  
> > zoo
> > .lose(
> > q, p)
> >  
> > Shouldn’t it be:
> >  
> > zoo
> > .lose(
> > q, p)
> >  
>  
>  
> Maybe, but that's harder to do. Basically, we'd want to keep the  
> additional 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 easy, but finding its  
> siblings - not so much.
>  
>  

I guess this can be ignored for now, since such code is not particularly common.  

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.