Anonymous function arguments are mangled in a very annoying way

[maxaf]

I've found that anonymous functions with arguments that aren't on the same line as the opening curly bracket end up moved to that line. There also doesn't appear to be a way to configure this behavior.

Am I missing an existing configuration option, or could one be added that would allow me to turn this off?

Here's an example of what I mean:

Before:

object HelloThere {
  val Things = "a" :: "b" :: Nil
  def foo {
    Things.foreach {
      thing =>
        println("_%s".format(thing))
    }
  }
}

After:

object HelloThere {
  val Things = "a" :: "b" :: Nil
  def foo {
    Things.foreach { thing =>
      println("_%s".format(thing))
    }
  }
}

[mdr]

Hmm, yeah, there's no option to control that right now. I think the best solution would be simply to have it leave the argument wherever it was originally.

[maxaf]

That would work for me. Thanks!
On May 19, 2011 5:48 PM, "mdr" <
reply@reply.github.com>
wrote:

[rktoomey]

Hi, I see that CompactEnsuringGap appears in 2c30ab9 but there doesn't appear to be a supported config param for it yet?

I can try to take care of this any send you a pull request if you like.

[mdr]

Yeah...the fix was just to preserve whatever was in the code -- i.e. output a newline before the parameter if and only if there was one in the source already. So no extra preference option needed to be added.

Are you saying you'd like a feature where the user could force it one way or the other with a preference?

[rktoomey]

oh yes - we absolutely hate having our anonymous function arguments
slurped back up to the preceding line.

coll.map {
v => v.somethingOrOther(blah, blah)
}

forcibly turns into

coll.map { v =>
v.somethingOrOther(blah, blah)
}

which i personally dislike, although i wasn't willing to go to the
wall for it like i was with the compact control readability style....
:)

i know how to add the preference everywhere from the so i could easily
put together a pull request for you tonight if that's ok.

On 26 July 2011 15:36, mdr
reply@reply.github.com
wrote:

Yeah...the fix was just to preserve whatever was in the code -- i.e. output a newline before the parameter if and only if there was one in the source already. So no extra preference option needed to be added.

Are you saying you'd like a feature where the user could force it one way or the other with a preference?

Reply to this email directly or view it on GitHub:
#21 (comment)

[mdr]

OK, cool...but just to make sure we're on the same page: the behaviour now is that it won't forcibly move the argument -- it will be left right where it is. It's "preserve" behaviour.

Adding a new preference then becomes a little more tricky because it's a tri-state: either force a newline before the parameter, force no newline before the parameter, or preserve a newline if there.

Your example reveals another problem I hadn't noticed -- the newline after the arrow. We now transform:

coll.map {
  v => v.somethingOrOther(blah, blah)
}

into

coll.map {
  v => 
    v.somethingOrOther(blah, blah)
}

Which I think is a mistake -- it should keep it on one line.

[rktoomey]

Actually, no need for anything - I reformatted the code last night
against 1.1-SNAPSHOT built from your latest checkin and everything
looks great!

On 26 July 2011 16:00, mdr
reply@reply.github.com
wrote:

OK, cool...but just to make sure we're on the same page: the behaviour now is that it won't forcibly move the argument -- it will be left right where it is. It's "preserve" behaviour.

Adding a new preference then becomes a little more tricky because it's a tri-state: either force a newline before the parameter, force no newline before the parameter, or preserve a newline if there.

Your example reveals another problem I hadn't noticed --  the newline after the arrow. We now transform:

coll.map {
 v => v.somethingOrOther(blah, blah)
}

into

coll.map {
 v =>
   v.somethingOrOther(blah, blah)
}

Which I think is a mistake -- it should keep it on one line.

Reply to this email directly or view it on GitHub:
#21 (comment)