From: Aaron Jensen <aaronjensen@gmail.com>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: 60186@debbugs.gnu.org
Subject: bug#60186: 29.0.60; ruby-mode indentation of multi-line expressions
Date: Tue, 20 Dec 2022 15:05:05 -0500 [thread overview]
Message-ID: <CAHyO48ybYrvkHbztSkUjLkh5vQWOVhBhi-7sdUqui5LZBrr5Rw@mail.gmail.com> (raw)
In-Reply-To: <358bbd65-9375-04c8-f0a2-24a4383f142e@yandex.ru>
On Tue, Dec 20, 2022 at 11:19 AM Dmitry Gutov <dgutov@yandex.ru> wrote:
>
> On 20/12/2022 06:48, Aaron Jensen wrote:
>
> > In all seriousness though,
> >
> >>> Current:
> >>>
> >>> some_variable = some_object.
> >>> some_method
> >>>
> >>> Desired:
> >>>
> >>> some_variable = some_object.
> >>> some_method
> >
> > This one isn't quite right, maybe there was an email formatting issue.
> > I'm expecting some_method to be indented by 1 level, for me it's 2:
> >
> > some_variable = some_object.
> > some_method
>
> Yes, that's also the "needs more work" part.
> some_variable = some_number + some_other_number *
> some_third_number +
> some_fourth_number -
> some_fifth_number
Yeah, with this I'd probably be trying to give a name to some of the
things (what is the name of the product there?) I don't think I've
ever seen code like that in practice to be honest.
>
> >>>
> >>> Current:
> >>>
> >>> some_variable = some_number + some_other_number *
> >>> some_third_number + some_fourth_number -
> >>> some_fifth_number
> >>>
> >>> Desired:
> >>>
> >>> some_variable = some_number + some_other_number *
> >>> some_third_number + some_fourth_number -
> >>> some_fifth_number
> >
> > This looks good.
>
> The funny thing is this case looked more difficult originally.
>
> >> This will take some more work too. Not in the least because the
> >> "Desired" forms looks illogical (at least in the context of SMIE): we're
> >> already "escaping" the current syntax node to line the indentation of
> >> the block to the beginning of the statement (which makes sense, at least
> >> from the ergonomics POV), so why would the line break matter?
> >
> > Do you mean why are these different?
> >
> > some_variable = some_array.
> > map do |x|
> > x + 1
> > end
> >
> > vs
> >
> > some_variable = some_array.map do |x|
> > x + 1
> > end
> >
> > It's because the end is lined up with the line opened the
> > block/increased indentation. In the first example, the indented map
> > line is the beginning and on the second, it's the assignment.
>
> One might ask why it's lined up to 'map' only after it's moved to the
> next line, but not in the first example.
It's never lined up to map, I don't think that's the right way to
think about it. It's lined up to indent level 1. It isn't until after
the `end' that the indent level returns to 0.
Line continuation (mid-expression): +1 indent level
Block opening (mid-block): +1 indent level
Paren opening (mid-arguments/params): +1 indent level
And all the closing/endings: -1 indent level
Only one indent level can be added per line, so all that matters is
where the line ends. In short, there are a set of expressions that
require indentation if they span multiple lines:
expression-start
expression-middle
expression-end
I haven't tried the patch yet, but I'll give it a shot.
Thank you,
Aaron
>
> Anyway, the important part is to choose an unambiguous algorithm, even
> if it uses its own logic.
>
> >> Take more complex cases. How much indentation will the block have after
> >> some heterogeneous continuations? Is this right?
> >>
> >> some_variable = 4 +
> >> some_array.
> >> reduce do |acc, x|
> >> acc + x
> >> end
> >
> > No, there is nothing that would cause reduce to be further indented.
> > It should be this:
> >
> > some_variable = 4 +
> > some_array.
> > reduce do |acc, x|
> > acc + x
> > end
>
> Okay, so there should be two basic cases:
>
> - Indent to the beginning of the statement,
> - If there was a line continuation (no matter how many), indent 1 extra
> level?
>
> And maybe something related to parentheses, if used.
next prev parent reply other threads:[~2022-12-20 20:05 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-19 2:54 bug#60186: 29.0.60; ruby-mode indentation of multi-line expressions Aaron Jensen
2022-12-20 2:12 ` Dmitry Gutov
2022-12-20 2:17 ` Dmitry Gutov
2022-12-20 4:48 ` Aaron Jensen
2022-12-20 5:56 ` Aaron Jensen
2022-12-20 15:53 ` Dmitry Gutov
2022-12-20 16:19 ` Dmitry Gutov
2022-12-20 17:31 ` Dmitry Gutov
2022-12-21 1:34 ` Aaron Jensen
2022-12-20 20:05 ` Aaron Jensen [this message]
2022-12-21 22:48 ` Dmitry Gutov
2022-12-22 2:31 ` Aaron Jensen
2022-12-22 21:21 ` Dmitry Gutov
2022-12-23 4:12 ` Aaron Jensen
2022-12-23 22:26 ` Dmitry Gutov
2022-12-24 0:17 ` Aaron Jensen
2022-12-24 22:47 ` Dmitry Gutov
2022-12-25 0:12 ` Aaron Jensen
2022-12-25 21:23 ` Dmitry Gutov
2022-12-25 21:29 ` bug#60321: 29.0.60; ruby-mode indentation of hash or array as first arg in multiline method call Dmitry Gutov
2022-12-25 23:46 ` Aaron Jensen
2022-12-27 1:16 ` Dmitry Gutov
2022-12-27 1:38 ` Aaron Jensen
2024-08-31 23:41 ` Aaron Jensen
2024-09-01 0:54 ` Aaron Jensen
2024-09-01 16:36 ` Dmitry Gutov
2024-09-01 19:28 ` Aaron Jensen
2024-09-02 0:19 ` Dmitry Gutov
2024-09-02 0:49 ` Aaron Jensen
2024-09-02 1:10 ` Dmitry Gutov
2024-09-02 1:56 ` Aaron Jensen
2024-09-02 19:01 ` Dmitry Gutov
2024-09-02 19:21 ` Aaron Jensen
2022-12-25 0:14 ` bug#60186: 29.0.60; ruby-mode indentation of multi-line expressions Aaron Jensen
2022-12-25 21:29 ` Dmitry Gutov
2022-12-27 1:28 ` Dmitry Gutov
2022-12-27 1:47 ` Aaron Jensen
2022-12-27 15:56 ` Dmitry Gutov
2022-12-27 16:34 ` Aaron Jensen
2022-12-27 23:04 ` Dmitry Gutov
2022-12-28 0:38 ` Aaron Jensen
2022-12-28 1:02 ` Dmitry Gutov
2022-12-28 3:47 ` Aaron Jensen
2022-12-28 12:47 ` Dmitry Gutov
2022-12-28 21:24 ` Dmitry Gutov
2022-12-29 22:59 ` Aaron Jensen
2022-12-30 15:02 ` Dmitry Gutov
2022-12-30 18:00 ` Aaron Jensen
2022-12-30 18:16 ` Aaron Jensen
2022-12-30 22:07 ` Dmitry Gutov
2022-12-31 1:11 ` Aaron Jensen
2023-01-22 3:02 ` Dmitry Gutov
2023-01-22 5:15 ` Aaron Jensen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAHyO48ybYrvkHbztSkUjLkh5vQWOVhBhi-7sdUqui5LZBrr5Rw@mail.gmail.com \
--to=aaronjensen@gmail.com \
--cc=60186@debbugs.gnu.org \
--cc=dgutov@yandex.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).