Chained trailing lambdas are formatted incorrectly

ktfmt currently formats this piece of code like this:

  private fun initializeRepository(repositoryDir: File) {
    val builder = FileRepositoryBuilder()
    repository =
      runCatching { builder.setGitDir(repositoryDir).build() }.getOrElse { e ->
        e.printStackTrace()
        null
      }
  }

While I would expect it to be something like this:

  private fun initializeRepository(repositoryDir: File) {
    val builder = FileRepositoryBuilder()
-    repository =
-      runCatching { builder.setGitDir(repositoryDir).build() }.getOrElse { e ->
-        e.printStackTrace()
-        null
-      }
+    repository = runCatching {
+      builder.setGitDir(repositoryDir).build()
+    }.getOrElse { e ->
+      e.printStackTrace()
+      null
+    }
  }

It seems that only the last lambda is considered for line breaks and not the intermediate one, which results in ktfmt assuming this line does not fit with the assignment and thus puts it on a new one.

[nreid260]

I believe under my proposal, we’d get something similar to what’s suggested in https://github.com/facebookincubator/ktfmt/issues/295#issuecomment-1052305658

This is a combination of two kind of tricky problems: what to do with long fluent chains, and should assignment statements be blocklike. There are approaches for both of these separately, but I don’t think they’ll combine very well. It’s easier to see why if we look at more potential cases that would need to work:

-----------------------------------------------------
someVar = foo.bar { some -> lambda }.zip(named = arg)

--------------------------------------------
someVar = foo.bar { some -> lambda }.zip(
  named = arg
)

------------------------------
someVar = foo
  .bar { some -> lambda }
  .zip(named = arg)

------------------------------ // This is tricky combo case
someVar =
  someReallyReallyLongRoot
    .bar { some -> lambda }
    .zip(named = arg)

----------------
someVar = foo
  .bar { some ->
    lambda
  }
  .zip(
    named = arg
  )

[strulovich]

Yes, this is pretty pereceptive. Unfortunately, some people for different methods would expect the given version.

@nreid260 is trying to find a golden path to describe our core rules to decide what to do. Maybe he would like to chime in.

In the short term, we’re unlikely to do this change though.