bug#60186: 29.0.60; ruby-mode indentation of multi-line expressions

[Aaron Jensen]

On Mon, Dec 19, 2022 at 9:12 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
>
> On 19/12/2022 04:54, Aaron Jensen wrote:
> >
> > Follow-up to bug#60110
>
> Thanks!
>
> > I prefer rather simplictic indentation for Ruby (and this appears to be
> > pretty common from codebases I've seen). Essentially, the rule is: If an
> > expression continues on another line, indent it once.
>
> FWIW, this feels a little wasteful -- working to emulate the editors
> which don't have much of a grammar definition, so they mostly line up
> things to the beginning of the previous line (plus maybe the indentation
> offset).
>
> But I guess that can make some experience better when working in teams.

The implication here is that the current indentation
rules are somehow objectively better. I'd argue the opposite,
                                      that they have usability issues.

:)

In all seriousness though,

> > Current:
> >
> > some_variable = some_object.
> >                    some_method
> >
> > Desired:
> >
> > some_variable = some_object.
> >    some_method

This one isn't quite right, maybe there was an email formatting issue.
I'm expecting some_method to be indented by 1 level, for me it's 2:

some_variable = some_object.
    some_method

> >
> > Current:
> >
> > some_variable = some_number + some_other_number *
> >                                some_third_number + some_fourth_number -
> >                  some_fifth_number
> >
> > Desired:
> >
> > some_variable = some_number + some_other_number *
> >    some_third_number + some_fourth_number -
> >    some_fifth_number

This looks good.
>
> This was easier to change than I expected, so here's some patch
> attached. It's very WIP -- before moving it to release some
> reorganization of indentation rules is in order, to be able to put the
> new option in just one place, and to streamline how indentation after
> "." works.
>
> This won't make it into 29.1, but we can put ruby-mode in ELPA after.
>
> > I don't know if this last one is related or not, but it follows the same
> > rule plus the rule about blocks. Everything about the continuation of
> > the expression is indented once. The contents of the block are indented
> > once more. The end should line up with the line that opened the block.
> >
> > Current:
> >
> > some_variable = some_array.
> >                    map do |x|
> >    x + 1
> > end
> >
> > Desired:
> >
> > some_variable = some_array.
> >    map do |x|
> >      x + 1
> >    end
>
> This will take some more work too. Not in the least because the
> "Desired" forms looks illogical (at least in the context of SMIE): we're
> already "escaping" the current syntax node to line the indentation of
> the block to the beginning of the statement (which makes sense, at least
> from the ergonomics POV), so why would the line break matter?

Do you mean why are these different?

some_variable = some_array.
  map do |x|
    x + 1
  end

vs

some_variable = some_array.map do |x|
  x + 1
end

It's because the end is lined up with the line opened the
block/increased indentation. In the first example, the indented map
line is the beginning and on the second, it's the assignment.

>
> Take more complex cases. How much indentation will the block have after
> some heterogeneous continuations? Is this right?
>
>    some_variable = 4 +
>      some_array.
>        reduce do |acc, x|
>          acc + x
>        end

No, there is nothing that would cause reduce to be further indented.
It should be this:

some_variable = 4 +
  some_array.
  reduce do |acc, x|
    acc + x
  end

> What if the continuations are all after the same operator?
>
>    some_variable = 4 +
>      some_var +
>      some_array.reduce do |acc, x|
>        acc + x
>      end
>
>    some_variable = some_var.
>      some_method.
>      map do |x|
>        x + 1
>      end

Yes, these look right.

Thanks,

Aaron