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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 60186 in the body.
You can then email your comments to 60186 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Aaron Jensen <aaronjensen <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.60; ruby-mode indentation of multi-line expressions
Date: Sun, 18 Dec 2022 21:54:18 -0500

Follow-up to bug#60110

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. 

Current:

some_variable = some_object.
                  some_method

Desired:

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


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

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Aaron Jensen <aaronjensen <at> gmail.com>, 60186 <at> debbugs.gnu.org
Subject: Re: bug#60186: 29.0.60; ruby-mode indentation of multi-line
 expressions
Date: Tue, 20 Dec 2022 04:12:39 +0200

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.

> Current:
> 
> some_variable = some_object.
>                    some_method
> 
> Desired:
> 
> 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 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?

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

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

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Aaron Jensen <aaronjensen <at> gmail.com>, 60186 <at> debbugs.gnu.org
Subject: Re: bug#60186: 29.0.60; ruby-mode indentation of multi-line
 expressions
Date: Tue, 20 Dec 2022 04:17:54 +0200

[Message part 1 (text/plain, inline)]

On 20/12/2022 04:12, Dmitry Gutov wrote:
> so here's some patch attached. It's very WIP

Here.

[ruby-simplistic-indent-wip.diff (text/x-patch, attachment)]

Message #14 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: Mon, 19 Dec 2022 23:48:39 -0500

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

Message #17 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: Tue, 20 Dec 2022 00:56:02 -0500

On Mon, Dec 19, 2022 at 11:48 PM Aaron Jensen <aaronjensen <at> gmail.com> wrote:
>
> 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,

Sorry, I was going to say, this style of indentation is more inline
with what I see in the wild in Ruby codebases and essentially every
other editor I've seen. Also, enh-ruby-mode is what I'm using as a
guide here, and it has a pretty much perfect grasp of the grammar
since it uses the Ruby parser. It's just a simpler indentation norm.

Aaron

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Aaron Jensen <aaronjensen <at> gmail.com>
Cc: 60186 <at> debbugs.gnu.org
Subject: Re: bug#60186: 29.0.60; ruby-mode indentation of multi-line
 expressions
Date: Tue, 20 Dec 2022 17:53:31 +0200

On 20/12/2022 07:56, Aaron Jensen wrote:
> On Mon, Dec 19, 2022 at 11:48 PM Aaron Jensen<aaronjensen <at> gmail.com>  wrote:
>> 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,
> Sorry, I was going to say, this style of indentation is more inline
> with what I see in the wild in Ruby codebases and essentially every
> other editor I've seen. Also, enh-ruby-mode is what I'm using as a
> guide here, and it has a pretty much perfect grasp of the grammar
> since it uses the Ruby parser. It's just a simpler indentation norm.

I do believe it's "better" in the sense that can give more hints to the 
user WRT to the program structure -- which, unlike in Lisp, is not 
always obvious. For example, this:

  some_variable = some_number + some_other_number *
                                some_third_number +
                  some_fourth_number -
                  some_fifth_number

conveys the implicit grouping, based on the operator precedence. It 
might be less important for * vs +, but others can be more obscure.

That's not to say that it must be everyone's cup of tea, or that you 
want it to look "lispy" every time. Ideally, there will always be a way 
to write the code, with default indentation config, that the result 
looks "mundane". E.g.

  some_variable = if true
                    2
                  else
                    3
                  end

=>

  some_variable =
    if true
      2
    else
      3
    end

(this is also customizable)

or

  some_method(foo,
              bar,
              baz)

=>

  some_method(
    foo,
    bar,
    baz
  )

And I'll be the first to admit that the current behavior still has some 
usability issues (though perhaps we'll disagree on the full list).

One example would be the previous bug report of yours, where the 
existing (the current default) behavior didn't really benefit anybody much.

Another -- expressions like

  some_method({
                foo: bar,
                tee: qux
              }, zzz)

where it's not 100% obvious what TRT is, but we could probably do better.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Aaron Jensen <aaronjensen <at> gmail.com>
Cc: 60186 <at> debbugs.gnu.org
Subject: Re: bug#60186: 29.0.60; ruby-mode indentation of multi-line
 expressions
Date: Tue, 20 Dec 2022 18:19:08 +0200

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.

>>>
>>> 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.

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.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Aaron Jensen <aaronjensen <at> gmail.com>
Cc: 60186 <at> debbugs.gnu.org
Subject: Re: bug#60186: 29.0.60; ruby-mode indentation of multi-line
 expressions
Date: Tue, 20 Dec 2022 19:31:31 +0200

[Message part 1 (text/plain, inline)]

On 20/12/2022 18:19, Dmitry Gutov wrote:
> 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?

Here's another quick attempt to make this work without rewriting the 
rest of the logic.

Cases 1 and 2 seem to work now, but not the block example.

[ruby-simplified-indent-v2.diff (text/x-patch, attachment)]

Message #29 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: Tue, 20 Dec 2022 15:05:05 -0500

On Tue, Dec 20, 2022 at 11:19 AM Dmitry Gutov <dgutov <at> 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.

Message #32 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: Tue, 20 Dec 2022 20:34:24 -0500

On Tue, Dec 20, 2022 at 12:31 PM Dmitry Gutov <dgutov <at> yandex.ru> wrote:
>
> On 20/12/2022 18:19, Dmitry Gutov wrote:
> > 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?
>
> Here's another quick attempt to make this work without rewriting the
> rest of the logic.
>
> Cases 1 and 2 seem to work now, but not the block example.

I haven't had a chance to try this yet, but I just wanted to mention
that we put the .'s on the end of multi-line expressions, but putting
them at the beginning is probably more common:

some_variable = some_method
  .map { |x| x + 1 }
  .uniq

I just wanted to mention that in case it mattered for the work you are doing.

Thanks,

Aaron

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Aaron Jensen <aaronjensen <at> gmail.com>
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 00:48:38 +0200

[Message part 1 (text/plain, inline)]

On 20/12/2022 22:05, Aaron Jensen wrote:
>>     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.

Sure, but if such complex structures are not used, it also doesn't 
matter that the ruby-mode indents them differently from the "community 
baseline".

But it could still help when prototyping code, fiddling with the 
implementation (to factor pieces out into named variables later), etc.

>> 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 think I got it. Only one indent level can be added for the duration of 
a statement. Unless there are nested blocks or parens/brackets/braces.

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

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).

[ruby-simplified-indent-v3.diff (text/x-patch, attachment)]

Message #38 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: Wed, 21 Dec 2022 21:31:14 -0500

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


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

Thanks,

Aaron

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Aaron Jensen <aaronjensen <at> gmail.com>
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:21:15 +0200

[Message part 1 (text/plain, inline)]

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.

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.

[ruby-simplified-indent-v4.diff (text/x-patch, attachment)]

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

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Aaron Jensen <aaronjensen <at> gmail.com>
Cc: 60186 <at> debbugs.gnu.org
Subject: Re: bug#60186: 29.0.60; ruby-mode indentation of multi-line
 expressions
Date: Sat, 24 Dec 2022 00:26:00 +0200

On 23/12/2022 06:12, Aaron Jensen wrote:

>> See the new one attached.
> 
> Seems to work well with everything I threw at it.

Thank you. I think I'll tinker with it and then push to master sometime 
later. Maybe after 29 RC is cut, or if I get to a nicer rewrite earlier.

>> 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.

Is that also true for the other "codebases you've seen" referred to in 
the first message here?

> The simplified style with the 2
> spaces means the first argument is on a different plane than the rest
> which negatively impacts scanning.

Makes sense.

> 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".

That's also my preference and true of the code I've seen. But "class 
level macros" are often an important part of projects, be that 
ActiveRecord validations, or DSL-like calls in Grape (routes, params, etc).

So I wonder whether we should alter parenless calls' indentation for the 
"simplified" style.

I checked out some popular projects out there. Rails' style is 
inconsistent, with class-level parenless calls lined up vertically and 
the rare use of them inside methods seem to go the "simplified" route. 
I'm not sure if that's intentional, or whether it's just written by 
different people.

Redmine mixes styles, but mostly on the side of lining up.

Spree lines up and overall seems to vindicate the default "lispy" 
indentation style, e.g. here:

https://github.com/spree/spree/blob/main/core/app/models/spree/zone.rb
https://github.com/spree/spree/blob/main/core/app/models/spree/tax_rate.rb

Though they also like to line up the keyword arguments according to 
Rubocop's defaults 
(https://github.com/spree/spree/blob/main/core/app/models/spree/product.rb#L63), 
something we don't support yet.

Do you have a source-available example of a project in your preferred 
coding style?

Chef, perhaps?

https://github.com/chef/chef/blob/main/lib/chef/application/base.rb
https://github.com/chef/chef/blob/main/lib/chef/application/client.rb

> This means that any time we decide to split a method invocation on
> multiple lines we use the basic newline after ( style.

For "class-level macros" as well?

Message #50 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: Fri, 23 Dec 2022 19:17:11 -0500

On Fri, Dec 23, 2022 at 5:26 PM Dmitry Gutov <dgutov <at> yandex.ru> wrote:
>
> Is that also true for the other "codebases you've seen" referred to in
> the first message here?

Mostly we work with Rails (and I try to avoid looking at that code as
much as I can, though I often find myself in there...) and the
Eventide framework: https://github.com/eventide-project

Given that the two founders of that are on my team we tend to follow
their indentation and coding style (and it is well-thought out, with
everything considered with respect to human cognition/eye tracking
studies/etc.). That's probably the best example I could offer, though
what you will find in there is that not many lines of code span more
than one line. They (and we) tend to allow longer lines when the right
side of the line is less important.

> > 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".
>
> That's also my preference and true of the code I've seen. But "class
> level macros" are often an important part of projects, be that
> ActiveRecord validations, or DSL-like calls in Grape (routes, params, etc).
>
> So I wonder whether we should alter parenless calls' indentation for the
> "simplified" style.

I think I would tend towards saying yes, make it simple/like the chef
codebase. That's consistent and if one wants to line things up, then
one can use parens, even with class level macros (or use long lines
and not care).

> I checked out some popular projects out there. Rails' style is
> inconsistent, with class-level parenless calls lined up vertically and
> the rare use of them inside methods seem to go the "simplified" route.
> I'm not sure if that's intentional, or whether it's just written by
> different people.
>
> Redmine mixes styles, but mostly on the side of lining up.
>
> Spree lines up and overall seems to vindicate the default "lispy"
> indentation style, e.g. here:
>
> https://github.com/spree/spree/blob/main/core/app/models/spree/zone.rb
> https://github.com/spree/spree/blob/main/core/app/models/spree/tax_rate.rb
>
> Though they also like to line up the keyword arguments according to
> Rubocop's defaults
> (https://github.com/spree/spree/blob/main/core/app/models/spree/product.rb#L63),
> something we don't support yet.

This line is rather painful to read and inconsistent with the call
just below it on line 70. I would certainly not advocate for that.

> Do you have a source-available example of a project in your preferred
> coding style?
>
> Chef, perhaps?
>
> https://github.com/chef/chef/blob/main/lib/chef/application/base.rb
> https://github.com/chef/chef/blob/main/lib/chef/application/client.rb

Yeah, I think this is probably the closest with regard to indentation
aside from Eventide, but again, you won't find much indentation there.
Whatever you find will likely be Vim's default, which I believe is the
same simple two space indent we are discussing.

> > This means that any time we decide to split a method invocation on
> > multiple lines we use the basic newline after ( style.
>
> For "class-level macros" as well?

I found inconsistencies in our codebase, so it is time for us to
establish a new norm. My guess is that we will land on using parens
for it. When we do it without parens, it is in the simplified style.

Thank you for your research and work on this, I appreciate it.

Aaron

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Aaron Jensen <aaronjensen <at> gmail.com>
Cc: 60186 <at> debbugs.gnu.org
Subject: Re: bug#60186: 29.0.60; ruby-mode indentation of multi-line
 expressions
Date: Sun, 25 Dec 2022 00:47:55 +0200

[Message part 1 (text/plain, inline)]

On 24/12/2022 02:17, Aaron Jensen wrote:
> On Fri, Dec 23, 2022 at 5:26 PM Dmitry Gutov <dgutov <at> yandex.ru> wrote:
>>
>> Is that also true for the other "codebases you've seen" referred to in
>> the first message here?
> 
> Mostly we work with Rails (and I try to avoid looking at that code as
> much as I can, though I often find myself in there...) and the
> Eventide framework: https://github.com/eventide-project

Thanks. It's very neat. I couldn't find any big app in there, though. 
And that's where the things tend to become more hairy.

> Given that the two founders of that are on my team we tend to follow
> their indentation and coding style (and it is well-thought out, with
> everything considered with respect to human cognition/eye tracking
> studies/etc.). That's probably the best example I could offer, though
> what you will find in there is that not many lines of code span more
> than one line. They (and we) tend to allow longer lines when the right
> side of the line is less important.

With code rarely spanning multiple lines, the current indentation logic 
of ruby-mode is probably working fine too.

>>> 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".
>>
>> That's also my preference and true of the code I've seen. But "class
>> level macros" are often an important part of projects, be that
>> ActiveRecord validations, or DSL-like calls in Grape (routes, params, etc).
>>
>> So I wonder whether we should alter parenless calls' indentation for the
>> "simplified" style.
> 
> I think I would tend towards saying yes, make it simple/like the chef
> codebase. That's consistent and if one wants to line things up, then
> one can use parens, even with class level macros (or use long lines
> and not care).

All right. In the latest iteration of the patch (attached) I've split 
off the block's indentation behavior into a separate option and altered 
the indentation of the parenless calls.

In the more complex cases the results are definitely interesting:

  method arg1,
    method2 arg2,
    arg3

  zzz = method (a + b),
    c, :d => :e,
    f: g

>> Though they also like to line up the keyword arguments according to
>> Rubocop's defaults
>> (https://github.com/spree/spree/blob/main/core/app/models/spree/product.rb#L63),
>> something we don't support yet.
> 
> This line is rather painful to read and inconsistent with the call
> just below it on line 70. I would certainly not advocate for that.

I think it's consistent in the sense that the "keyword" section of the 
arguments is vertically aligned in both cases. It's a popular Rubocop 
rule, apparently.

Whether it's useful, though, I'm doubtful too.

>> Do you have a source-available example of a project in your preferred
>> coding style?
>>
>> Chef, perhaps?
>>
>> https://github.com/chef/chef/blob/main/lib/chef/application/base.rb
>> https://github.com/chef/chef/blob/main/lib/chef/application/client.rb
> 
> Yeah, I think this is probably the closest with regard to indentation
> aside from Eventide, but again, you won't find much indentation there.
> Whatever you find will likely be Vim's default, which I believe is the
> same simple two space indent we are discussing.

Okay.

>>> This means that any time we decide to split a method invocation on
>>> multiple lines we use the basic newline after ( style.
>>
>> For "class-level macros" as well?
> 
> I found inconsistencies in our codebase, so it is time for us to
> establish a new norm. My guess is that we will land on using parens
> for it. When we do it without parens, it is in the simplified style.
> 
> Thank you for your research and work on this, I appreciate it.

Thank you too.

We could also discuss cases like

  foo = bar({
              tee: 1,
              qux: 2
           })

  baz([
        1,
        2,
        3
      ])

but those would be an orthogonal feature. And I don't see them much in 
the wild, for some reason.

[ruby-simplified-indent-v5.diff (text/x-patch, attachment)]

Message #56 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: Sat, 24 Dec 2022 19:12:39 -0500

On Sat, Dec 24, 2022 at 5:47 PM Dmitry Gutov <dgutov <at> yandex.ru> wrote:
>
> On 24/12/2022 02:17, Aaron Jensen wrote:
> > On Fri, Dec 23, 2022 at 5:26 PM Dmitry Gutov <dgutov <at> yandex.ru> wrote:
> >>
> >> Is that also true for the other "codebases you've seen" referred to in
> >> the first message here?
> >
> > Mostly we work with Rails (and I try to avoid looking at that code as
> > much as I can, though I often find myself in there...) and the
> > Eventide framework: https://github.com/eventide-project
>
> Thanks. It's very neat. I couldn't find any big app in there, though.
> And that's where the things tend to become more hairy.

Funny thing, that. That's intentional. Our client's codebase we built
doesn't have any big apps either. Different subject though.


> > Given that the two founders of that are on my team we tend to follow
> > their indentation and coding style (and it is well-thought out, with
> > everything considered with respect to human cognition/eye tracking
> > studies/etc.). That's probably the best example I could offer, though
> > what you will find in there is that not many lines of code span more
> > than one line. They (and we) tend to allow longer lines when the right
> > side of the line is less important.
>
> With code rarely spanning multiple lines, the current indentation logic
> of ruby-mode is probably working fine too.

We see more in our application (and that's closed source, so I cannot
share it). Suffice it to say, it came up enough that all the Emacs
users on our team have had trouble with it, so this work will be
appreciated.

> >>> 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".
> >>
> >> That's also my preference and true of the code I've seen. But "class
> >> level macros" are often an important part of projects, be that
> >> ActiveRecord validations, or DSL-like calls in Grape (routes, params, etc).
> >>
> >> So I wonder whether we should alter parenless calls' indentation for the
> >> "simplified" style.
> >
> > I think I would tend towards saying yes, make it simple/like the chef
> > codebase. That's consistent and if one wants to line things up, then
> > one can use parens, even with class level macros (or use long lines
> > and not care).
>
> All right. In the latest iteration of the patch (attached) I've split
> off the block's indentation behavior into a separate option and altered
> the indentation of the parenless calls.
>
> In the more complex cases the results are definitely interesting:
>
>    method arg1,
>      method2 arg2,
>      arg3

I don't know what I'd expect here, other than to have a conversation
with the dev who wrote it to explain why we use parentheses :) In
other words, I'm fine with this indentation and I couldn't even tell
you the precedence here off the top of my head.

>    zzz = method (a + b),
>      c, :d => :e,
>      f: g

Yeah, this looks right to me too.


> >> Though they also like to line up the keyword arguments according to
> >> Rubocop's defaults
> >> (https://github.com/spree/spree/blob/main/core/app/models/spree/product.rb#L63),
> >> something we don't support yet.
> >
> > This line is rather painful to read and inconsistent with the call
> > just below it on line 70. I would certainly not advocate for that.
>
> I think it's consistent in the sense that the "keyword" section of the
> arguments is vertically aligned in both cases. It's a popular Rubocop
> rule, apparently.
>
> Whether it's useful, though, I'm doubtful too.
>
> >> Do you have a source-available example of a project in your preferred
> >> coding style?
> >>
> >> Chef, perhaps?
> >>
> >> https://github.com/chef/chef/blob/main/lib/chef/application/base.rb
> >> https://github.com/chef/chef/blob/main/lib/chef/application/client.rb
> >
> > Yeah, I think this is probably the closest with regard to indentation
> > aside from Eventide, but again, you won't find much indentation there.
> > Whatever you find will likely be Vim's default, which I believe is the
> > same simple two space indent we are discussing.
>
> Okay.
>
> >>> This means that any time we decide to split a method invocation on
> >>> multiple lines we use the basic newline after ( style.
> >>
> >> For "class-level macros" as well?
> >
> > I found inconsistencies in our codebase, so it is time for us to
> > establish a new norm. My guess is that we will land on using parens
> > for it. When we do it without parens, it is in the simplified style.
> >
> > Thank you for your research and work on this, I appreciate it.
>
> Thank you too.
>
> We could also discuss cases like
>
>    foo = bar({
>                tee: 1,
>                qux: 2
>             })
>
>    baz([
>          1,
>          2,
>          3
>        ])
>
> but those would be an orthogonal feature. And I don't see them much in
> the wild, for some reason.

The same logic would apply. It doesn't matter how many indent starters
there are in a line, the indentation should only increase by one:


foo = bar({
  tee: 1,
  qux: 2
})

baz([
  1,
  2,
  3
])

Of course, that begs the question what happens if you do this:

baz([
  1,
  2,
  3
]
)

And, I think again, the answer is a social one, rather than a technical one.

enh-ruby-mode and vim both do this this:

baz([
  1,
  2,
  3
]
   )

I would not even attempt to explain why in this situation they rely on
lining up parens, but this is what they do. So, we could either
emulate this, or chart our own course. I would have expected it to
look like the example I gave with the ] and ) both at the beginning of
the line with no indentation. The Vim way looks worse though, which in
this instance may be a feature :)

Aaron

Message #59 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: Sat, 24 Dec 2022 19:14:30 -0500

On Sat, Dec 24, 2022 at 5:47 PM Dmitry Gutov <dgutov <at> yandex.ru> wrote:
>
> All right. In the latest iteration of the patch (attached) I've split
> off the block's indentation behavior into a separate option and altered
> the indentation of the parenless calls.

I forgot to mention that I tried the patch out and it seems to work well with:

(setq ruby-indent-simplified t
      ruby-block-indent nil)

Those are the only two I should be setting, correct?

Thanks,

Aaron

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#60186: 29.0.60; ruby-mode indentation of multi-line
 expressions
Date: Sun, 25 Dec 2022 23:23:45 +0200

X-Debbugs-CC: aaronjensen <at> gmail.com

Splitting off from debbugs#60186.

Since this setting also seems orthogonal to the "simplified" preference, 
and it'll require some more work.

On 25/12/2022 02:12, Aaron Jensen wrote:
>> We could also discuss cases like
>>
>>     foo = bar({
>>                 tee: 1,
>>                 qux: 2
>>              })
>>
>>     baz([
>>           1,
>>           2,
>>           3
>>         ])
>>
>> but those would be an orthogonal feature. And I don't see them much in
>> the wild, for some reason.
> The same logic would apply. It doesn't matter how many indent starters
> there are in a line, the indentation should only increase by one:
> 
> 
> foo = bar({
>    tee: 1,
>    qux: 2
> })
> 
> baz([
>    1,
>    2,
>    3
> ])
> 
> Of course, that begs the question what happens if you do this:
> 
> baz([
>    1,
>    2,
>    3
> ]
> )

Here are a couple trickier examples:

takes_multi_pairs_hash(x: {
  a: 1,
  b: 2
})

and_in_a_method_call({
  no: :difference
},
foo,
bar)

AFAICT even Rubocop doesn't have a setting which would indent the second 
one somewhat reasonably, while keeping two-space indent before "no".

> And, I think again, the answer is a social one, rather than a technical one.
> 
> enh-ruby-mode and vim both do this this:
> 
> baz([
>    1,
>    2,
>    3
> ]
>     )

Yup, that looks pretty bizarre. OTOH, I don't see why a developer would 
put a newline between "]" and ")" in this case.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Aaron Jensen <aaronjensen <at> gmail.com>
Cc: 60186 <at> debbugs.gnu.org
Subject: Re: bug#60186: 29.0.60; ruby-mode indentation of multi-line
 expressions
Date: Sun, 25 Dec 2022 23:29:42 +0200

On 25/12/2022 02:14, Aaron Jensen wrote:
> On Sat, Dec 24, 2022 at 5:47 PM Dmitry Gutov<dgutov <at> yandex.ru>  wrote:
>> All right. In the latest iteration of the patch (attached) I've split
>> off the block's indentation behavior into a separate option and altered
>> the indentation of the parenless calls.
> I forgot to mention that I tried the patch out and it seems to work well with:
> 
> (setq ruby-indent-simplified t
>        ruby-block-indent nil)
> 
> Those are the only two I should be setting, correct?

Yep.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Aaron Jensen <aaronjensen <at> gmail.com>
Cc: 60186 <at> debbugs.gnu.org
Subject: Re: bug#60186: 29.0.60; ruby-mode indentation of multi-line
 expressions
Date: Tue, 27 Dec 2022 03:28:53 +0200

On 25/12/2022 02:14, Aaron Jensen wrote:
> (setq ruby-indent-simplified t

BTW, do you have any opinion on the name? Perhaps something more 
semantic would be easier to discover.

A recent tree-sitter thread brought up sh-indent-after-continuation. 
It's not a direct counterpart, though, and the examples only look 
remotely similar.

Call ours ruby-indent-continuations-simplified, maybe? Now that we seem 
to have reduced its scope to expression continuations across newlines.

Hopefully it won't be confused with Kernel#callcc.

Message #71 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: Mon, 26 Dec 2022 20:47:44 -0500

On Mon, Dec 26, 2022 at 8:28 PM Dmitry Gutov <dgutov <at> yandex.ru> wrote:
>
> On 25/12/2022 02:14, Aaron Jensen wrote:
> > (setq ruby-indent-simplified t
>
> BTW, do you have any opinion on the name? Perhaps something more
> semantic would be easier to discover.
>
> A recent tree-sitter thread brought up sh-indent-after-continuation.
> It's not a direct counterpart, though, and the examples only look
> remotely similar.
>
> Call ours ruby-indent-continuations-simplified, maybe? Now that we seem
> to have reduced its scope to expression continuations across newlines.
>
> Hopefully it won't be confused with Kernel#callcc.

Simple is what it is in comparison to something more complex. All
indentations are pretty much about line continuation in one way or
another.

What is it on its own? I'm not sure.

Some food for thought:

Unaligned
Beginning of line aligned
Standard
Incremental
Snap-to-grid
K&R style
C style
Egyptian brackets
Not Lisp style
Lisp alignment: false
Argument alignment: false

Sort of a smattering there, but maybe it'll jog something for you.

Aaron

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Aaron Jensen <aaronjensen <at> gmail.com>
Cc: 60186 <at> debbugs.gnu.org
Subject: Re: bug#60186: 29.0.60; ruby-mode indentation of multi-line
 expressions
Date: Tue, 27 Dec 2022 17:56:14 +0200

On 27/12/2022 03:47, Aaron Jensen wrote:
> On Mon, Dec 26, 2022 at 8:28 PM Dmitry Gutov <dgutov <at> yandex.ru> wrote:
>>
>> On 25/12/2022 02:14, Aaron Jensen wrote:
>>> (setq ruby-indent-simplified t
>>
>> BTW, do you have any opinion on the name? Perhaps something more
>> semantic would be easier to discover.
>>
>> A recent tree-sitter thread brought up sh-indent-after-continuation.
>> It's not a direct counterpart, though, and the examples only look
>> remotely similar.
>>
>> Call ours ruby-indent-continuations-simplified, maybe? Now that we seem
>> to have reduced its scope to expression continuations across newlines.
>>
>> Hopefully it won't be confused with Kernel#callcc.
> 
> Simple is what it is in comparison to something more complex.

Just 1 indent vs arbitrary number of indents depending on operator 
priority/ast nesting. Seems like "simpler" is appropriate.

> All
> indentations are pretty much about line continuation in one way or
> another.

Okay, how about ruby-indent-operator-continuation?

Or ruby-indent-binary-op-continuation. Which would include all binary 
operators and method calls. *shrug* We could also split off the method 
call indentation to a separate option too.

> What is it on its own? I'm not sure.
> 
> Some food for thought:
> 
> Unaligned

That might be a good adjective (if we take it to mean, not aligned to 
the closest parent AST node), but something else to narrow down the 
scope is needed in the name. ruby-operator-unaligned-indent?

ruby-operator-shallow-indent?

> Beginning of line aligned

Beginning of statement, I guess?

> Standard

"Standard" is a point of view. ;-)

Message #77 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: Tue, 27 Dec 2022 11:34:26 -0500

On Tue, Dec 27, 2022 at 10:56 AM Dmitry Gutov <dgutov <at> yandex.ru> wrote:
>
> On 27/12/2022 03:47, Aaron Jensen wrote:
> > On Mon, Dec 26, 2022 at 8:28 PM Dmitry Gutov <dgutov <at> yandex.ru> wrote:
> >>
> >> On 25/12/2022 02:14, Aaron Jensen wrote:
> >>> (setq ruby-indent-simplified t
> >>
> >> BTW, do you have any opinion on the name? Perhaps something more
> >> semantic would be easier to discover.
> >>
> >> A recent tree-sitter thread brought up sh-indent-after-continuation.
> >> It's not a direct counterpart, though, and the examples only look
> >> remotely similar.
> >>
> >> Call ours ruby-indent-continuations-simplified, maybe? Now that we seem
> >> to have reduced its scope to expression continuations across newlines.
> >>
> >> Hopefully it won't be confused with Kernel#callcc.
> >
> > Simple is what it is in comparison to something more complex.
>
> Just 1 indent vs arbitrary number of indents depending on operator
> priority/ast nesting. Seems like "simpler" is appropriate.

Right, but that was my point. The name doesn't stand on its own. It
only stands relative to some other more complex indentation scheme. If
we can find a name that stands on its own, I think that would be
better.

> > All
> > indentations are pretty much about line continuation in one way or
> > another.
>
> Okay, how about ruby-indent-operator-continuation?
>
> Or ruby-indent-binary-op-continuation. Which would include all binary
> operators and method calls. *shrug* We could also split off the method
> call indentation to a separate option too.

Right, maybe it makes sense to consider one of two directions:

1. A single option to enable this "simple" indentation mode, i.e.
ruby-indent-alignment: line/statement/start/beginning vs. sibling/end
2. Split each different rule into its own option and name them
according to the specific circumstance the rule covers. I still don't
know what the options would be.

That said, when you say method calls, you mean the '.' operator, yes?
I see what you're getting at with this naming and I think it's
probably cohesive enough to be one option per #2 above.

> > What is it on its own? I'm not sure.
> >
> > Some food for thought:
> >
> > Unaligned
>
> That might be a good adjective (if we take it to mean, not aligned to
> the closest parent AST node), but something else to narrow down the
> scope is needed in the name. ruby-operator-unaligned-indent?
>
> ruby-operator-shallow-indent?
>
> > Beginning of line aligned
>
> Beginning of statement, I guess?

Yeah, that would be better than line

> > Standard
>
> "Standard" is a point of view. ;-)

Indeed... there is also https://github.com/testdouble/standard but I
think it's a bit of a land grab to call it standard and I've never
really looked at it.


I put incremental in the last list since I was trying to get at the
fact that the indentation increases by one increment at a time. Is
there something about it being that vs it context-aware? Obviously all
indentation is context aware, so I'm not sure that that's the right
direction.

Aaron

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Aaron Jensen <aaronjensen <at> gmail.com>
Cc: 60186 <at> debbugs.gnu.org
Subject: Re: bug#60186: 29.0.60; ruby-mode indentation of multi-line
 expressions
Date: Wed, 28 Dec 2022 01:04:45 +0200

On 27/12/2022 18:34, Aaron Jensen wrote:

>>> Simple is what it is in comparison to something more complex.
>>
>> Just 1 indent vs arbitrary number of indents depending on operator
>> priority/ast nesting. Seems like "simpler" is appropriate.
> 
> Right, but that was my point. The name doesn't stand on its own. It
> only stands relative to some other more complex indentation scheme. If
> we can find a name that stands on its own, I think that would be
> better.

That's true.

But it seems we've rejected most of each other's suggestions by now.

>>> All
>>> indentations are pretty much about line continuation in one way or
>>> another.
>>
>> Okay, how about ruby-indent-operator-continuation?
>>
>> Or ruby-indent-binary-op-continuation. Which would include all binary
>> operators and method calls. *shrug* We could also split off the method
>> call indentation to a separate option too.
> 
> Right, maybe it makes sense to consider one of two directions:
> 
> 1. A single option to enable this "simple" indentation mode, i.e.
> ruby-indent-alignment: line/statement/start/beginning vs. sibling/end
> 2. Split each different rule into its own option and name them
> according to the specific circumstance the rule covers. I still don't
> know what the options would be.
> 
> That said, when you say method calls, you mean the '.' operator, yes?
> I see what you're getting at with this naming and I think it's
> probably cohesive enough to be one option per #2 above.

Right. If we consider "." as something distinct, it could use a separate 
option. Or not. But it's trivial to separate.

>> "Standard" is a point of view. ;-)
> 
> Indeed... there is also https://github.com/testdouble/standard but I
> think it's a bit of a land grab to call it standard and I've never
> really looked at it.

Concur.

> I put incremental in the last list since I was trying to get at the
> fact that the indentation increases by one increment at a time.

IDK, there might be different connotations, e.g. it always grows (though 
slowly).

>  Is
> there something about it being that vs it context-aware?
> Obviously all
> indentation is context aware, so I'm not sure that that's the right
> direction.

"More" context-aware, one could say. Or less. But that's the same as 
"simpler".

I suppose we could call it structural..? The current behavior, that is. 
As in 
https://github.com/yairchu/awesome-structure-editors#structural-code-editor-projects.

Or here's a step back: looking at how the two other user options I named 
previously were ruby-method-params-indent and ruby-block-indent, the 
latest might as well be called ruby-operator-indent, or 
ruby-operator-indent and ruby-method-call-indent.

I wasn't too crazy about those names originally, but the approach is 
very extensible with styles by adding new symbols as possible values.

Message #83 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: Tue, 27 Dec 2022 19:38:14 -0500

On Tue, Dec 27, 2022 at 6:04 PM Dmitry Gutov <dgutov <at> yandex.ru> wrote:
>
> On 27/12/2022 18:34, Aaron Jensen wrote:
>
> >>> Simple is what it is in comparison to something more complex.
> >>
> >> Just 1 indent vs arbitrary number of indents depending on operator
> >> priority/ast nesting. Seems like "simpler" is appropriate.
> >
> > Right, but that was my point. The name doesn't stand on its own. It
> > only stands relative to some other more complex indentation scheme. If
> > we can find a name that stands on its own, I think that would be
> > better.
>
> That's true.
>
> But it seems we've rejected most of each other's suggestions by now.
>
> >>> All
> >>> indentations are pretty much about line continuation in one way or
> >>> another.
> >>
> >> Okay, how about ruby-indent-operator-continuation?
> >>
> >> Or ruby-indent-binary-op-continuation. Which would include all binary
> >> operators and method calls. *shrug* We could also split off the method
> >> call indentation to a separate option too.
> >
> > Right, maybe it makes sense to consider one of two directions:
> >
> > 1. A single option to enable this "simple" indentation mode, i.e.
> > ruby-indent-alignment: line/statement/start/beginning vs. sibling/end
> > 2. Split each different rule into its own option and name them
> > according to the specific circumstance the rule covers. I still don't
> > know what the options would be.
> >
> > That said, when you say method calls, you mean the '.' operator, yes?
> > I see what you're getting at with this naming and I think it's
> > probably cohesive enough to be one option per #2 above.
>
> Right. If we consider "." as something distinct, it could use a separate
> option. Or not. But it's trivial to separate.
>
> >> "Standard" is a point of view. ;-)
> >
> > Indeed... there is also https://github.com/testdouble/standard but I
> > think it's a bit of a land grab to call it standard and I've never
> > really looked at it.
>
> Concur.
>
> > I put incremental in the last list since I was trying to get at the
> > fact that the indentation increases by one increment at a time.
>
> IDK, there might be different connotations, e.g. it always grows (though
> slowly).
>
>  >  Is
>  > there something about it being that vs it context-aware?
> > Obviously all
> > indentation is context aware, so I'm not sure that that's the right
> > direction.
>
> "More" context-aware, one could say. Or less. But that's the same as
> "simpler".
>
> I suppose we could call it structural..? The current behavior, that is.
> As in
> https://github.com/yairchu/awesome-structure-editors#structural-code-editor-projects.
>
> Or here's a step back: looking at how the two other user options I named
> previously were ruby-method-params-indent and ruby-block-indent, the
> latest might as well be called ruby-operator-indent, or
> ruby-operator-indent and ruby-method-call-indent.
>
> I wasn't too crazy about those names originally, but the approach is
> very extensible with styles by adding new symbols as possible values.

This may end up being the right direction. If the values are symbols
you can use things that are relative to one another like "simple".
There could be a benefit to all of these having a "simple" option.
What would it mean if it were nil?
What's the current behavior called?

It may be that if we only intend to support two indentation schemes we
just have default and simplified as you suggested and then we can use
boolean values. I don't know how Emacs-like this is, but what if there
were one variable like `ruby-indent-simple` that could either be `t`
or a list of things to indent simply?

Aaron

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Aaron Jensen <aaronjensen <at> gmail.com>
Cc: 60186 <at> debbugs.gnu.org
Subject: Re: bug#60186: 29.0.60; ruby-mode indentation of multi-line
 expressions
Date: Wed, 28 Dec 2022 03:02:11 +0200

On 28/12/2022 02:38, Aaron Jensen wrote:

>> Or here's a step back: looking at how the two other user options I named
>> previously were ruby-method-params-indent and ruby-block-indent, the
>> latest might as well be called ruby-operator-indent, or
>> ruby-operator-indent and ruby-method-call-indent.
>>
>> I wasn't too crazy about those names originally, but the approach is
>> very extensible with styles by adding new symbols as possible values.
> 
> This may end up being the right direction. If the values are symbols
> you can use things that are relative to one another like "simple".
> There could be a benefit to all of these having a "simple" option.
> What would it mean if it were nil?
> What's the current behavior called?

For the sake of uniformity, I wanted to start with simple values -- t 
and nil, and explain their meanings in the docstring.

't' would mean the current behavior, and I'd call it "structural", or 
structure-based indentation. Or based on implicit expression grouping.

> It may be that if we only intend to support two indentation schemes we
> just have default and simplified as you suggested and then we can use
> boolean values. I don't know how Emacs-like this is, but what if there
> were one variable like `ruby-indent-simple` that could either be `t`
> or a list of things to indent simply?

That can work too, but what is "simple"? ;-)

Further, I'm not sure if we're going to get more than 2 "things" this 
way (operators and method calls). OTOH, if we have a separate var for 
operators -- ruby-operator-indent -- we could enumerate which operators 
to indent "structurally" after. Or something like that.

Not sure which direction the feature requests will drive this extension 
toward, though. Maybe mostly nowhere, given the previous history. But 
Rubocop's example seems to indicate that there are many different styles 
out there.

Message #89 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: Tue, 27 Dec 2022 22:47:23 -0500

On Tue, Dec 27, 2022 at 8:02 PM Dmitry Gutov <dgutov <at> yandex.ru> wrote:
>
> On 28/12/2022 02:38, Aaron Jensen wrote:
>
> >> Or here's a step back: looking at how the two other user options I named
> >> previously were ruby-method-params-indent and ruby-block-indent, the
> >> latest might as well be called ruby-operator-indent, or
> >> ruby-operator-indent and ruby-method-call-indent.
> >>
> >> I wasn't too crazy about those names originally, but the approach is
> >> very extensible with styles by adding new symbols as possible values.
> >
> > This may end up being the right direction. If the values are symbols
> > you can use things that are relative to one another like "simple".
> > There could be a benefit to all of these having a "simple" option.
> > What would it mean if it were nil?
> > What's the current behavior called?
>
> For the sake of uniformity, I wanted to start with simple values -- t
> and nil, and explain their meanings in the docstring.
>
> 't' would mean the current behavior, and I'd call it "structural", or
> structure-based indentation. Or based on implicit expression grouping.

I'd typically not use t and nil on anything but a boolean and the name
would be named after what t represents, but this may be an Emacs idiom
that is OK. If so, and there's no better options (i.e., going against
that idiom is worse than not), then that works for me.


> > It may be that if we only intend to support two indentation schemes we
> > just have default and simplified as you suggested and then we can use
> > boolean values. I don't know how Emacs-like this is, but what if there
> > were one variable like `ruby-indent-simple` that could either be `t`
> > or a list of things to indent simply?
>
> That can work too, but what is "simple"? ;-)
>
> Further, I'm not sure if we're going to get more than 2 "things" this
> way (operators and method calls). OTOH, if we have a separate var for
> operators -- ruby-operator-indent -- we could enumerate which operators
> to indent "structurally" after. Or something like that.
>
> Not sure which direction the feature requests will drive this extension
> toward, though. Maybe mostly nowhere, given the previous history. But
> Rubocop's example seems to indicate that there are many different styles
> out there.

Yeah, hard to say, and it may eventually become less important if
ruby-ts comes about and has enough options to satisfy folks with
different ideas about indentation.

Aaron

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Aaron Jensen <aaronjensen <at> gmail.com>
Cc: 60186 <at> debbugs.gnu.org
Subject: Re: bug#60186: 29.0.60; ruby-mode indentation of multi-line
 expressions
Date: Wed, 28 Dec 2022 14:47:12 +0200

On 28/12/2022 05:47, Aaron Jensen wrote:
> On Tue, Dec 27, 2022 at 8:02 PM Dmitry Gutov <dgutov <at> yandex.ru> wrote:
>>
>> On 28/12/2022 02:38, Aaron Jensen wrote:
>>
>>>> Or here's a step back: looking at how the two other user options I named
>>>> previously were ruby-method-params-indent and ruby-block-indent, the
>>>> latest might as well be called ruby-operator-indent, or
>>>> ruby-operator-indent and ruby-method-call-indent.
>>>>
>>>> I wasn't too crazy about those names originally, but the approach is
>>>> very extensible with styles by adding new symbols as possible values.
>>>
>>> This may end up being the right direction. If the values are symbols
>>> you can use things that are relative to one another like "simple".
>>> There could be a benefit to all of these having a "simple" option.
>>> What would it mean if it were nil?
>>> What's the current behavior called?
>>
>> For the sake of uniformity, I wanted to start with simple values -- t
>> and nil, and explain their meanings in the docstring.
>>
>> 't' would mean the current behavior, and I'd call it "structural", or
>> structure-based indentation. Or based on implicit expression grouping.
> 
> I'd typically not use t and nil on anything but a boolean and the name
> would be named after what t represents, but this may be an Emacs idiom
> that is OK. If so, and there's no better options (i.e., going against
> that idiom is worse than not), then that works for me.

I guess that particular trend started with ruby-method-params-indent, 
where I haven't managed to choose better names for the var, or the values.

>>> It may be that if we only intend to support two indentation schemes we
>>> just have default and simplified as you suggested and then we can use
>>> boolean values. I don't know how Emacs-like this is, but what if there
>>> were one variable like `ruby-indent-simple` that could either be `t`
>>> or a list of things to indent simply?
>>
>> That can work too, but what is "simple"? ;-)
>>
>> Further, I'm not sure if we're going to get more than 2 "things" this
>> way (operators and method calls). OTOH, if we have a separate var for
>> operators -- ruby-operator-indent -- we could enumerate which operators
>> to indent "structurally" after. Or something like that.
>>
>> Not sure which direction the feature requests will drive this extension
>> toward, though. Maybe mostly nowhere, given the previous history. But
>> Rubocop's example seems to indicate that there are many different styles
>> out there.
> 
> Yeah, hard to say, and it may eventually become less important if
> ruby-ts comes about and has enough options to satisfy folks with
> different ideas about indentation.

ruby-ts-mode might have extra flexibility down the line, but at the 
start I want to have it obey the same indentation options as ruby-mode.

BTW, you can check out its progress at 
https://github.com/pedz/ruby-ts-mode/.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Aaron Jensen <aaronjensen <at> gmail.com>
Cc: 60186 <at> debbugs.gnu.org
Subject: Re: bug#60186: 29.0.60; ruby-mode indentation of multi-line
 expressions
Date: Wed, 28 Dec 2022 23:24:06 +0200

[Message part 1 (text/plain, inline)]

On 28/12/2022 14:47, Dmitry Gutov wrote:
> I guess that particular trend started with ruby-method-params-indent, 
> where I haven't managed to choose better names for the var, or the values.

Semantics aside (I suppose we could go back and revise the naming a 
little later), could you test this new revision of the patch?

I think I got the implementation simple enough now.

The number of options has grown, though:

(setq ruby-after-operator-indent nil
      ruby-block-indent nil
      ruby-method-call-indent nil
      ruby-parenless-call-arguments-indent nil)

[ruby-simplified-indent-v6.diff (text/x-patch, attachment)]

Message #98 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, 29 Dec 2022 17:59:18 -0500

On Wed, Dec 28, 2022 at 4:24 PM Dmitry Gutov <dgutov <at> yandex.ru> wrote:
>
> On 28/12/2022 14:47, Dmitry Gutov wrote:
> > I guess that particular trend started with ruby-method-params-indent,
> > where I haven't managed to choose better names for the var, or the values.
>
> Semantics aside (I suppose we could go back and revise the naming a
> little later), could you test this new revision of the patch?
>
> I think I got the implementation simple enough now.
>
> The number of options has grown, though:
>
> (setq ruby-after-operator-indent nil
>        ruby-block-indent nil
>        ruby-method-call-indent nil
>        ruby-parenless-call-arguments-indent nil)

I'll give it a shot some more, but these appear problematic:

fixture(
EntityProjection::Fixtures::Projection,
projection,
deleted
) do |projection|
  projection.assert_attributes_copied([
    { :document_id => :id }
                                      ])
end

Should be:

fixture(
  EntityProjection::Fixtures::Projection,
  projection,
  deleted
) do |projection|
  projection.assert_attributes_copied([
    { :document_id => :id }
  ])
end

Aaron

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Aaron Jensen <aaronjensen <at> gmail.com>
Cc: 60186 <at> debbugs.gnu.org
Subject: Re: bug#60186: 29.0.60; ruby-mode indentation of multi-line
 expressions
Date: Fri, 30 Dec 2022 17:02:26 +0200

Hi Aaron,

On 30/12/2022 00:59, Aaron Jensen wrote:
> On Wed, Dec 28, 2022 at 4:24 PM Dmitry Gutov<dgutov <at> yandex.ru>  wrote:
>> On 28/12/2022 14:47, Dmitry Gutov wrote:
>>> I guess that particular trend started with ruby-method-params-indent,
>>> where I haven't managed to choose better names for the var, or the values.
>> Semantics aside (I suppose we could go back and revise the naming a
>> little later), could you test this new revision of the patch?
>>
>> I think I got the implementation simple enough now.
>>
>> The number of options has grown, though:
>>
>> (setq ruby-after-operator-indent nil
>>         ruby-block-indent nil
>>         ruby-method-call-indent nil
>>         ruby-parenless-call-arguments-indent nil)
> I'll give it a shot some more, but these appear problematic:
> 
> fixture(
> EntityProjection::Fixtures::Projection,
> projection,
> deleted
> ) do|projection|
>    projection.assert_attributes_copied([
>      { :document_id => :id }
>                                        ])
> end
> 
> Should be:
> 
> fixture(
>    EntityProjection::Fixtures::Projection,
>    projection,
>    deleted
> ) do|projection|
>    projection.assert_attributes_copied([
>      { :document_id => :id }
>    ])
> end

This example is for https://debbugs.gnu.org/60321, I think. Which we 
split off and postponed a little.

The last patch was the latest revision of the changes for 
https://debbugs.gnu.org/60186.

As long as this example is unchanged (indented the same as the current 
version of ruby-mode), it's good enough. It looks like this on my 
machine, though:

  fixture(
    EntityProjection::Fixtures::Projection,
    projection,
    deleted
  ) do |projection|
    projection.assert_attributes_copied([
                                          { :document_id => :id }
                                        ])
  end

Could you please give the v6 patch a good run soon-ish: we have a good 
chance of getting it into Emacs 29 (together with ruby-ts-mode, which 
should reuse some or most of the options), as I've just found out.

The deadline for checking all this in is pretty near, alas: 1-2 days.

Message #104 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: Fri, 30 Dec 2022 13:00:09 -0500

On Fri, Dec 30, 2022 at 10:02 AM Dmitry Gutov <dgutov <at> yandex.ru> wrote:
>
> Hi Aaron,
>
> On 30/12/2022 00:59, Aaron Jensen wrote:
> > On Wed, Dec 28, 2022 at 4:24 PM Dmitry Gutov<dgutov <at> yandex.ru>  wrote:
> >> On 28/12/2022 14:47, Dmitry Gutov wrote:
> >>> I guess that particular trend started with ruby-method-params-indent,
> >>> where I haven't managed to choose better names for the var, or the values.
> >> Semantics aside (I suppose we could go back and revise the naming a
> >> little later), could you test this new revision of the patch?
> >>
> >> I think I got the implementation simple enough now.
> >>
> >> The number of options has grown, though:
> >>
> >> (setq ruby-after-operator-indent nil
> >>         ruby-block-indent nil
> >>         ruby-method-call-indent nil
> >>         ruby-parenless-call-arguments-indent nil)
> > I'll give it a shot some more, but these appear problematic:
> >
> > fixture(
> > EntityProjection::Fixtures::Projection,
> > projection,
> > deleted
> > ) do|projection|
> >    projection.assert_attributes_copied([
> >      { :document_id => :id }
> >                                        ])
> > end
> >
> > Should be:
> >
> > fixture(
> >    EntityProjection::Fixtures::Projection,
> >    projection,
> >    deleted
> > ) do|projection|
> >    projection.assert_attributes_copied([
> >      { :document_id => :id }
> >    ])
> > end
>
> This example is for https://debbugs.gnu.org/60321, I think. Which we
> split off and postponed a little.
>
> The last patch was the latest revision of the changes for
> https://debbugs.gnu.org/60186.

My mistake, it seems to work for these things aside from the method
params in the example below. I can't reproduce that in emacs -Q, only
with my own config, so I will have to see if I can figure out what the
difference is.


> As long as this example is unchanged (indented the same as the current
> version of ruby-mode), it's good enough. It looks like this on my
> machine, though:
>
>    fixture(
>      EntityProjection::Fixtures::Projection,
>      projection,
>      deleted
>    ) do |projection|
>      projection.assert_attributes_copied([
>                                            { :document_id => :id }
>                                          ])
>    end
>
> Could you please give the v6 patch a good run soon-ish: we have a good
> chance of getting it into Emacs 29 (together with ruby-ts-mode, which
> should reuse some or most of the options), as I've just found out.
>
> The deadline for checking all this in is pretty near, alas: 1-2 days.

Message #107 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: Fri, 30 Dec 2022 13:16:35 -0500

On Fri, Dec 30, 2022 at 1:00 PM Aaron Jensen <aaronjensen <at> gmail.com> wrote:
>
> On Fri, Dec 30, 2022 at 10:02 AM Dmitry Gutov <dgutov <at> yandex.ru> wrote:
> >
> > Hi Aaron,
> >
> > On 30/12/2022 00:59, Aaron Jensen wrote:
> > > On Wed, Dec 28, 2022 at 4:24 PM Dmitry Gutov<dgutov <at> yandex.ru>  wrote:
> > >> On 28/12/2022 14:47, Dmitry Gutov wrote:
> > >>> I guess that particular trend started with ruby-method-params-indent,
> > >>> where I haven't managed to choose better names for the var, or the values.
> > >> Semantics aside (I suppose we could go back and revise the naming a
> > >> little later), could you test this new revision of the patch?
> > >>
> > >> I think I got the implementation simple enough now.
> > >>
> > >> The number of options has grown, though:
> > >>
> > >> (setq ruby-after-operator-indent nil
> > >>         ruby-block-indent nil
> > >>         ruby-method-call-indent nil
> > >>         ruby-parenless-call-arguments-indent nil)
> > > I'll give it a shot some more, but these appear problematic:
> > >
> > > fixture(
> > > EntityProjection::Fixtures::Projection,
> > > projection,
> > > deleted
> > > ) do|projection|
> > >    projection.assert_attributes_copied([
> > >      { :document_id => :id }
> > >                                        ])
> > > end
> > >
> > > Should be:
> > >
> > > fixture(
> > >    EntityProjection::Fixtures::Projection,
> > >    projection,
> > >    deleted
> > > ) do|projection|
> > >    projection.assert_attributes_copied([
> > >      { :document_id => :id }
> > >    ])
> > > end
> >
> > This example is for https://debbugs.gnu.org/60321, I think. Which we
> > split off and postponed a little.
> >
> > The last patch was the latest revision of the changes for
> > https://debbugs.gnu.org/60186.
>
> My mistake, it seems to work for these things aside from the method
> params in the example below. I can't reproduce that in emacs -Q, only
> with my own config, so I will have to see if I can figure out what the
> difference is.


I can't reproduce this anymore, I think it had to do w/ dtrt-indent
doing something odd. I had things in a state where some buffers did it
and not others and I restarted Emacs before checking the settings. In
any case, I think it's fine. I don't have any concerns with the patch
as-is.

Thanks,

Aaron

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Aaron Jensen <aaronjensen <at> gmail.com>
Cc: 60186-done <at> debbugs.gnu.org
Subject: Re: bug#60186: 29.0.60; ruby-mode indentation of multi-line
 expressions
Date: Sat, 31 Dec 2022 00:07:16 +0200

Version: 29.1

On 30/12/2022 20:16, Aaron Jensen wrote:
> I can't reproduce this anymore, I think it had to do w/ dtrt-indent
> doing something odd. I had things in a state where some buffers did it
> and not others and I restarted Emacs before checking the settings. In
> any case, I think it's fine. I don't have any concerns with the patch
> as-is.

Thanks for testing, this is now in the release branch.

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

From: Aaron Jensen <aaronjensen <at> gmail.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 60186-done <at> debbugs.gnu.org
Subject: Re: bug#60186: 29.0.60;
 ruby-mode indentation of multi-line expressions
Date: Fri, 30 Dec 2022 17:11:33 -0800

[Message part 1 (text/plain, inline)]

 Thank you.


Aaron

On Fri, Dec 30 2022 at 5:07 PM, Dmitry Gutov <dgutov <at> yandex.ru> wrote:

> Version: 29.1
>
> On 30/12/2022 20:16, Aaron Jensen wrote:
>
> I can't reproduce this anymore, I think it had to do w/ dtrt-indent doing
> something odd. I had things in a state where some buffers did it and not
> others and I restarted Emacs before checking the settings. In any case, I
> think it's fine. I don't have any concerns with the patch as-is.
>
> Thanks for testing, this is now in the release branch.
>

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

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Aaron Jensen <aaronjensen <at> gmail.com>
Cc: 60186-done <at> debbugs.gnu.org
Subject: Re: bug#60186: 29.0.60; ruby-mode indentation of multi-line
 expressions
Date: Sun, 22 Jan 2023 05:02:40 +0200

Hi Aaron,

Now might be good to test how ruby-ts-mode works with all ruby-mode's 
indentation variables, too. If you have the time.

It should work support all of them now, but I might have missed some 
edge cases.

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

From: Aaron Jensen <aaronjensen <at> gmail.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 60186-done <at> debbugs.gnu.org
Subject: Re: bug#60186: 29.0.60;
 ruby-mode indentation of multi-line expressions
Date: Sun, 22 Jan 2023 00:15:11 -0500

On Sat, Jan 21, 2023 at 10:02 PM Dmitry Gutov <dgutov <at> yandex.ru> wrote:
>
> Hi Aaron,
>
> Now might be good to test how ruby-ts-mode works with all ruby-mode's
> indentation variables, too. If you have the time.
>
> It should work support all of them now, but I might have missed some
> edge cases.

Hi Dmitry,

I played around with it briefly and nothing stood out. It looks pretty
good. I'll try switching to it for daily use and report back if I find
anything. Thank you.

Aaron

Previous Next

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