GNU bug report logs - #60186
29.0.60; ruby-mode indentation of multi-line expressions

Previous Next

Full log

Message #44 received at 60186 <at> debbugs.gnu.org (full text, mbox):

From: Aaron Jensen <aaronjensen <at> gmail.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 60186 <at> debbugs.gnu.org
Subject: Re: bug#60186: 29.0.60;
 ruby-mode indentation of multi-line expressions
Date: Thu, 22 Dec 2022 23:12:53 -0500

On Thu, Dec 22, 2022 at 4:21 PM Dmitry Gutov <dgutov <at> yandex.ru> wrote:
>
> On 22/12/2022 04:31, Aaron Jensen wrote:
> > On Wed, Dec 21, 2022 at 5:48 PM Dmitry Gutov <dgutov <at> yandex.ru> wrote:
> >> See this new patch instead.
> >>
> >> The code is messier than I'd like it to be, but it seems to handle all
> >> of the cases mentioned so far and more (including the
> >> dots-at-indentation style, thanks).
> >
> > Looks good, for the things I mentioned. I found one more case:
> >
> > x.foo do
> >    foo
> > end.bar do
> >      bar
> >    end
> >
> > Should be:
> >
> > x.foo do
> >    foo
> > end.bar do
> >    bar
> > end
>
> Hm, this one breaks the approach I used with the last patch (which was
> to count lines from the beginning of the statement).
>
> Let's see if blocks can just be aligned to the indentation of its
> opener's line.
>
> > I can't vouch for writing in this style, but it should only get one
> > indentation increase in this instance, rather than, I believe.
> >
> > Interestingly enough, I found a bug with enh-ruby-mode that ruby-mode
> > now indents correctly:
> >
> > x =
> >    bar(
> >      y
> >    ).map do |i|
> >    i
> >    end
>
> Cool. It seems I broke it for the default indent algo, however. ;-( In
> the previous patch.
>
> See the new one attached.

Seems to work well with everything I threw at it.

> BTW, I'm surprised you haven't mentioned the case of parenless calls:
>
> foo bar,
>      baz,
>      tee
>
> IUUC the Rails core has decided to forgo this indentation style. Not
> sure about the statistics across other popular projects.

I try to avoid this style in general. The simplified style with the 2
spaces means the first argument is on a different plane than the rest
which negatively impacts scanning. With either indentation style, the
first argument (which is the most significant one when a method is
properly designed) will have the least presence when scanning. It's
just not a good format in my experience. In our code we take it a step
further and always use parentheses except for in class level "macros".
This means that any time we decide to split a method invocation on
multiple lines we use the basic newline after ( style.

Aaron

Previous Next

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