A big challenge is func-call and chain-access. It can be divided into two cases, not considering comments:

#{
  // If we can put everything except the arguments of the last one in one line and the last one is *heavy enough*.
  a.b().c().d(
    e(..)
  )
  
  // Otherwise, chain them.
  a
    .b(..)
    .c(..)
    .d(e(..))
}

We don't want to see an item in the middle split into multiple lines while there exists .a().b().

Some insights about comment handling.

We can abstract a line as before item, after, where before and after are comments.
When we see:

• a comment, we add it to free_comments for future use.
• a list item, if we have any free comments, join them together.
• a comma, we attach all free comments to the last item we saw (if any).
• a line break, if there is an item in the same line, attach free comments to the last one.

If the items are in a single line, we put the attached block comment before the comma. Otherwise after the comma. So the comma positions may change.

BTW, is dot chain formatting still a problem? I haven't examine snapshots yet. I can help take a look if the problem still present.

BTW, is dot chain formatting still a problem? I haven't examine snapshots yet. I can help take a look if the problem still present.

I haven't touched it yet, so the chain formatting is expected to remain unchanged.
I will work on it in the next PR.

It also fixes a bug that an array with one item is not broke into multiple lines when the column is narrow.

For closure parameters, I do not make "one parameter" a special case (although it easy to implement), to align with the format behavior of multiple parameters. So this is a breaking change. Since the structure of a closure has not been handled very well yet, this change may cause dissatisfaction.

BTW please consider editing the PR description to reflect latest changes. thanks!