GNU bug report logs -
#60186
29.0.60; ruby-mode indentation of multi-line expressions
Previous Next
Reported by: Aaron Jensen <aaronjensen <at> gmail.com>
Date: Mon, 19 Dec 2022 02:55:02 UTC
Severity: normal
Found in version 29.0.60
Fixed in version 29.1
Done: Dmitry Gutov <dgutov <at> yandex.ru>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
On Mon, Dec 19, 2022 at 9:12 PM Dmitry Gutov <dgutov <at> 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
This bug report was last modified 2 years and 175 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.