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

[Aaron Jensen]

On Tue, Dec 20, 2022 at 11:19 AM Dmitry Gutov <dgutov@yandex.ru> wrote:
>
> On 20/12/2022 06:48, Aaron Jensen wrote:
>
> > 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
>
> Yes, that's also the "needs more work" part.

>    some_variable = some_number + some_other_number *
>                                 some_third_number +
>                   some_fourth_number -
>                   some_fifth_number

Yeah, with this I'd probably be trying to give a name to some of the
things (what is the name of the product there?) I don't think I've
ever seen code like that in practice to be honest.

>
> >>>
> >>> 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.
>
> The funny thing is this case looked more difficult originally.
>
> >> 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.
>
> One might ask why it's lined up to 'map' only after it's moved to the
> next line, but not in the first example.

It's never lined up to map, I don't think that's the right way to
think about it. It's lined up to indent level 1. It isn't until after
the `end' that the indent level returns to 0.

Line continuation (mid-expression): +1 indent level
Block opening (mid-block): +1 indent level
Paren opening (mid-arguments/params): +1 indent level
And all the closing/endings: -1 indent level

Only one indent level can be added per line, so all that matters is
where the line ends. In short, there are a set of expressions that
require indentation if they span multiple lines:

expression-start
  expression-middle
expression-end

I haven't tried the patch yet, but I'll give it a shot.

Thank you,

Aaron

>
> Anyway, the important part is to choose an unambiguous algorithm, even
> if it uses its own logic.
>
> >> 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
>
> Okay, so there should be two basic cases:
>
> - Indent to the beginning of the statement,
> - If there was a line continuation (no matter how many), indent 1 extra
> level?
>
> And maybe something related to parentheses, if used.