scala-ide/scalariform

Anonymous function arguments are mangled in a very annoying way

maxaf opened this issue · 7 comments

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 commented

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.

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

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 commented

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?

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 commented

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.

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)