daniel-trinh / scalariform Goto Github PK

see scala-ide#37 and scala-ide#51

It is quite common to be editing in a codebase, that is not using scalariform, and to want to only reformat the lines of code that you've touched (thereby avoiding merge hell with other feature branches and PRs).

In particular I'd like to be able to do this via the ENSIME programmatic call to scalariform, and I can imagine others wanting the same in scala-ide.

I'm using lists in Scaladoc:

      /** Documentation
        *
        *  - item 1
        *  - item 2
        */

Note the two spaces between * and - item 1, which are necessary to make it a list. My problem is that scalariform reduces these two spaces to one, thus destroying the list structure.

Is there a way to deal with that?

It could help to strip down useless blank lines, I usually set it to 0 in IntelliJ.

It should override maxBlankLines (#69).

<maxBlankLinesAfterOpeningBrace>0</maxBlankLinesAfterOpeningBrace>
<maxBlankLinesBeforeClosingBrace>0</maxBlankLinesBeforeClosingBrace>

Re reading the docs it does not seem apparent to me any rule touches this area however locally when I ran v1.4 via scalariformFormat and examined changes I see imports cleaned up which is great but I cannot understand which rule was responsible. Since I am running 1.4 I included scalariformSettings in my build.sbt ... I dug into that setting as well but couldn't find an answer

explicitly named arguments are not indented properly if expression contains parenthesis and is followed my a method call.

Applies to 1.5.1 (and before)

expected

def foo(
  arg = bar(
   baz = "a"
  ).xyz
)

actual

def foo(
  arg = bar(
  baz = "a"
).xyz
)

probably related to #25

It would be neat to be able to brew install scalariform to use the standalone cli jar on OSX.

Things to do:

• Finish #52 so the CLI jar is up in maven central
• Create a homebrew formula that points to the cli jar

although I agree entirely with the new trailing newline behaviour, there does not appear to be a way to reproduce the old behaviour. This makes it difficult to include this version of scalariform in projects until it is safe to do a global reformat.

Please consider including a flag that reproduces the old behaviour.

The PreserveSpaceBeforeArguments setting appears to be doing more than it claims to.

When it is set to false, the following snippet:

Seq(1,2,3).foreach{ println }

becomes this:

Seq(1,2,3).foreach { println }

Notice that a space is inserted between foreach and {. The documentation for the setting makes no mention of this.

Annotations for expressions in blocks and parameter clauses currently are placed on the same line:

def asdf(
  @annotation one: Int,
  @a @b(c) two: String
)

class A extends B {
  @SomeImportantAnnotation(param = true) override val param: Int = 1

  @NotSoImportantAnnotation(param = false) val description: String = "Not so important"
}

Instead, it should be formatted as..

def asdf(
  @annotation 
  one: Int,
  @a 
  @b(c) 
  two: String
)

class A extends B {
  @SomeImportantAnnotation(param = true) 
  override val param: Int = 1

  @NotSoImportantAnnotation(param = false) 
  val description: String = "Not so important"
}

This would most likely only affect parameters that are already placed on their own line, so
something like this wouldn't be affected:

def asdf(@annotation one: Int, @a @b(c) two: String)

stays as..

def asdf(@annotation one: Int, @a @b(c) two: String)

Implementation details note: this needs to be implemented without breaking the AlignParameters feature

See here for similar issue on original branch: scala-ide#91

I am a newcomer to scala, and I have been trying to build an executable jar with sbt for two days. I am ignorant, definitely, but I have tried many, many ways of compiling this software for use in vim as a source code formatter, from sbt compile, to sbt publish, to sbt package, to using the sbt-assembly plugin and sbt assembly. My jar is never runnable, including all the classpaths I can find, etc., etc. I cannot get it right. Can you provide simple documentation on how to go from git repo to executable scalariform.jar?

The website link for this project is still http://mdr.github.io/scalariform/.

In the long run this won't work if you need to update the documentation. But it also is confusing for the abandoned repo to still host the current website (which is linked to by many other sites).

Ideally the site could be published to http://daniel-trinh.github.io/scalariform.

Scalariform supports rewriting => and <- into unicode equivalents. It would be neat if -> rewriting was also supported. I am aware that the former are tokens of Scala grammar and the latter is a library function defined in scala.Predef. However, most users would probably expect it to be treated as an "arrow symbol". It's quite widespread and according to my knowledge is the only function in the standard library that has a non-ASCII alias, so I think it would be reasonable to add support for it.

I'd suggest either updating the dependency to 4.0.0 (current version recommended at https://github.com/typesafehub/sbteclipse as of 25-Oct-2015)...

...or removing it entirely, and just let people add the plugin in their global sbt settings if they are Eclipse users

Currently, this

def something(a: Int,
  b: String, 
  c: Boolean)(d: Int,
  e: String, 
  f: Boolean)

is reformatted to this

def something(a: Int,
              b: String, 
              c: Boolean)(d: Int,
                          e: String, 
                          f: Boolean)

It would be simpler to just have it force the parameter onto a newline:

def something(
  a: Int,
  b: String, 
  c: Boolean)(
    d: Int,
    e: String, 
    f: Boolean)

or

def something(
  a: Int,
  b: String, 
  c: Boolean)(
  d: Int,
  e: String, 
  f: Boolean)

Reasoning for this: The "force to newline" version is already valid Scalariform formatting, which will occur if the user places the first parameter on a newline themselves. It'd be simpler to maintain the formatting code if only one of these versions were supported, and would be easier for people to read / get used to, since multi line arguments would always be formatted in the same way.

I think we should copy open issue from orginal scalariform repository here and inform submitters about it.

In analogy to formatting match { case => ... } statements it would be awesome if there would be support for for comprehensions, e.g.

for {
  a <- something
  anotherValue <- foo
} yield {
  ...
}

becomes

for {
  a            <- something
  anotherValue <- foo
} yield {
 ...
}

Changelog:

0.1.5 (4/May/14)
* FIX: Type formatter crash on multiline types
* Track scalac parser -- allow trait-position parents to have parameter blocks
* Sync changes to InferredSemicolonParser
* FIX: Scaladoc formatting wasn't idempotent (issue #62)
* Added "SpacesAroundMultiImports" option
* Added "AlignArguments" option
* Modified "AlignParameters" option to align by column -- see readme
* Deprecated "PreserveDanglingCloseParenthesis" in favor of
  automatic parentheses level detection.

Most significant changes are related to parentheses handling, behaviour of AlignParameters, and the addition of AlignArguments. See README for details.

To use with sbt:

resolvers += "Sonatype OSS Releases" at "https://oss.sonatype.org/content/repositories/releases"

addSbtPlugin("com.danieltrinh" % "sbt-scalariform" % "1.3.0")

or standalone:

resolvers += "Sonatype OSS Releases" at "https://oss.sonatype.org/content/repositories/releases"

libraryDependencies += "com.danieltrinh" % "scalariform" % "0.1.5"

val m = Map(
  "a" -> 1,
  "bb" -> 2,
  "ccc" -> 3
)

is formatted as:

val m = Map(
  "a"   -> 1,
  "bb"  -> 2,
  "ccc" -> 3
)

It would be great to be able to sort imports using scalariform.
Without automatic imports sorting teams are suffering from merge conflicts and unorganized imports mess.

There is the same issue in old project: scala-ide#67.

Multi-clause arguments and parameters are currently indented:

def something(
  a: Int,
  b: String, 
  c: Boolean)(
    d: Int,
    e: String, 
    f: Boolean)

If #7 and #8 is implemented, the extra indentation for visual feedback wouldn't be needed, and something like this would be enough:

def something(
  a: Int,
  b: String, 
  c: Boolean
)(
  d: Int,
  e: String, 
  f: Boolean
)

AlignArguments does not properly format multi line argument clauses when there are two or more arguments on the same line, and one of the arguments spans more than one line:

A(
  short = short, longParamName = Map(
  one -> two
)
)

Failing test:

Format failure:
 ---- Expected ----
A(
  short         = short,
  longParamName = Map(
    one -> two
  )
)
 ---- but was-----
A(
  short         = short, longParamName = Map(
  one -> two
)
)

If possible, it would be more convenient to follow a simple rule on whether
or not to place dangling parentheses on a newline or not: If the arguments or parameters are multi line, force a dangling parenthesis. If they are single line, place them on the same line.

This would most likely be implemented as part of #7.

Examples:

def something(
  a: Int,
  b: String, 
  c: Boolean)(
  d: Int,
  e: String, 
  f: Boolean)

becomes

def something(
  a: Int,
  b: String, 
  c: Boolean
)(
  d: Int,
  e: String, 
  f: Boolean
)

And something like this

A(
  B(a, b, c
  ),
  C(b, c, d
  ))

Becomes this

A(
  B(a, b, c),
  C(b, c, d)
)

currently in the Scala community build we are using an old version of Scalariform. we would like to standardize on ScalaTest 2.2.x in the community build; would it be possible for you to upgrade...?

currently scalariform only supports aligning single line case statements, eg.

case foo: Foo => ...
case bar         => ...

but it would be good if there was an option for multi line cases and also if there was a similar thing for variable definitions. At the very least, an option not to reformat the location of the = for variable definitions would be good.

In an example like this:

trait Context
case class Thing()(mk: Context ⇒ Int ⇒ Unit)

// what I want:
Thing() { implicit ctx ⇒ j ⇒
  ???
}

yet scalariform forces this to be formatted as (breaking the line after the first function arrow):

// what scalariform forces
Thing() { implicit ctx ⇒ 
  j ⇒
    ???
}

Making the entire thing less readable. We need this to be formulated like this because the ctx needs to be implicit, and it wouldn't work with making it a function of Tuple2.

Is there a setting I've missed which could disable this formatting or will this need to be fixed?

For code that looks like:

(option1, option2) match {
  case (Some(Object(_, "property value")), _) |
    (None, None)                                       => 5
  case (None, Some(Object(_, "other property value"))) => 6
  case _                                               => 7
}

It gets rewritten to:

(option1, option2) match {
  case (Some(Object(_, "property value")), _) |
    (None, None) => 5
  case (None, Some(Object(_, "other property value"))) => 6
  case _                                               => 7
}

It would be nice to have the option to have case statements with multi-line LHS to still have their RHS aligned

From scalariform --help:

--test, -t Check the input(s) to see if they are correctly formatted, return a non-zero error code if not.

However, it seems to be doing the opposite:

$ scalariform --test Formatted.scala
[OK]     Formatted.scala

$ echo $?
1

$ scalariform --test Unformatted.scala
[FAILED] Unformatted.scala

$ echo $?
0

It could help to strip down useless blank lines, I usually set it to 1 in IntelliJ.

<maxBlankLines>1</maxBlankLines>

When using IntelliJ, I often select a few lines and comment them, which places // in the beginning of the line.
This has several advantages. I want to be able to uncomment it later and have it working, but scalaiform messes it up:

• it idents the comments so the indentation of the uncommented code is now wrong

• more importantly, it removes inner comments so that comments in the uncommented code become uncommented!!

  {
      blah(0);
  //    blah(1);
  //    // FIXME make this test pass
  //    blah(2);
  }
  

Becomes:

    {
        blah(0);
        // blah();
        // FIXME make this test pass
        // blah();
    }

I'd really appreciate to have a preference switch to prevent comments from being refactored.
I am currently forced to use scalaiform in a project, and this is a productivity killer...

PS: using /* */ comments instead is too tedious and not an option.

• Undo #40
• Switch publish namespace from com.danieltrinh to org.scalariform
• Create dummy project that points the com.danieltrinh stuff to org.scalariform, so users don't have to switch namespaces in their code (although they will still have to switch versions)
• Update release notes, scala versions

It is fairly standard practice in implicit-heavy libraries to write implicit parameter lists like this

  def canBuildFromFormat[F, E, T]()(implicit
    cbf: CanBuildFrom[F, E, T],
    ef: SexpFormat[E]
  )

but unfortunately I can't set up scalariform to use this trailing-implicit format. Is this something you could support with a new option?

Note that it is possible to do this sort of thing

  def canBuildFromFormat[F, E, T]()(
    implicit
    cbf: CanBuildFrom[F, E, T],
    ef: SexpFormat[E]
  )

It would be great to have an InsertNewlineAtEof preference to go along with scalastyle's NewLineAtEofChecker.

its awesome that you were able to get the org.scalariform publishing rights 😄

It would still help out a lot if you could publish the empty packages under your namespace to simply pull in the org.scalariform jars. It is needed to resolve the classpath problems where a project depends on the com.danieltrinh sbt-plugin but another plugin (e.g. ENSIME) depends on the latest org.scalariform -- which version of scalariform is determined randomly.

I'd be happy to help send you an example of such a project if you'd like! In Maven these are called "pom only" projects. I've done this sort of thing in the past when I've migrated a group/artefact name (exactly the same as here) https://github.com/fommil/netlib-java/tree/master/legacy

Worst case scenario, if we can't figure out the sbt magic, is to just use maven to do a pom-only release 😄 Only needs to be done once.

I'm sure I had a ticket for this. But it seems to have disappeared. Maybe I dreamt it.

One of the biggest changes introduced by this fork was better dangling parenthesis behaviour. However, there is no option to get the old behaviour and this is stopping people from being able to upgrade scalariform, or in some extreme cases (like at my work) Eclipse.

Can you please look into this or let us know how to add the option. This is becoming really quite critical for me.

Hi,
first I want to thank you for this fork. After testing with the sbt-scalariform plugin ("com.danieltrinh" %% "sbt-scalariform" % "1.3.0") I found some problems with alignment of the parameters:

With 2 parameters, it's either

def donothing(foo: User, bar: Int): Int = {
  //
}

or

def donothing(
  foo: Int,
  bar: Int
): Int = {
  //
}

I cannot seem to get something like this:

def donothing(foo: Int,
              bar: Int): Int = {
  //
}

With 3 parameters, the format seem to depends on how I breaks the parameters list. If I break after the first 2 then I get (which is IMO the supposed result):

def donothing(foo: Int, bar: Int,
              baz: Int): Int = {
  //
}

If I breaks after foo: Int,, I always get:

  def donothing(
    foo: Int,
    bar: Int, baz: Int
  ): Int = {
    //
  }

or

  def donothing(
    foo: Int,
    bar: Int,
    baz: Int
  ): Int = {
    //
  }

Again, isn't something like this should be possible:

  def donothing(foo: Int,
                bar: Int,
                baz: Int): Int = {
    //
  }

The same goes for case class and class. I think it behaves the same like function. I hope you can fix this soon, since my class look something like this:

class Foo(
  foo: Int,
  bar: Int
) {
  //
}

and not

class Foo(
  foo: Int,
  bar: Int) {
  //
}

or

class Foo(foo: Int,
          bar: Int) {
  //
}

My setting is alignParameters -> true, alignArguments -> true, preserveDanglingCloseParenthesis -> true.

The parser fails at this case with the error Expected token RBRACKET but got Token(DOT,.,89,.):

object FailingCase {
  def failingMethod(v: Any) =
    v match {
      case v: List[scala.Int] => v
    }
}

Changing scala.Int to Int makes it work.

Since upgrading recently, I've been seeing errors to parse this trivial file:

package org.ensime.indexer

import org.apache.lucene.document._

package object lucene {
  implicit class RichEntity[T <: Entity](e: T) {
    def toDocument(implicit p: DocumentProvider[T]) = p.toDocument(e)
  }

  implicit class RichDocument(d: Document) {
    def toEntity[T](implicit p: DocumentRecovery[T]) = p.toEntity(d)
  }
}

with the error

[warn] Scalariform parser error for /path/to/file.scala: Expected token RBRACKET but got Token(XML_START_OPEN,<,865,<)

the offset matches 865 is [T <: Entity] on the file on disk (I've removed a bunch of irrelevant scaladocs here).

re the discussion at scala-ide#130

Please could you clarify the following?

• Is this now "the current "considered active" fork" of scalariform?
  • Considered by whom?
  • How might scalariform users know to use this fork instead of mdrs?
• Do you publish a JAR to any public Maven repos?
  • The latest I can find is https://maven-repository.com/artifact/org.scalariform/scalariform_2.10/0.1.4 which was publised by mdr on 2013-04-24
• What is fixed here v.s. the mdr original?
• Do you accept PRs for new features, or just fixes?
• Do you know what mdr thinks about the project?

Thanks,

Rich

it would be great if you could move your repo to a "scalariform-bak" and get the original author to hand ownership to you, as this appears to be the only maintained branch. At the same time, asking him to give you permissions to publish to org.scalariform would be wonderful (that would make it easier to get the sbt-plugin to use your branch).

Or, maybe the right thing is to create a scalariform organisation and get the original author to move the repo to there, adding you as dev/admin/whatever.

Scalariform is too important to rot.

          Stats(
            id = x.toInt,
            a  = calculateA(
              i   = i,
              rr  = rr,
              arr = arr
            ).toLong,
            c  = calculateC(
              c   = c,
              cc  = cc,
              ccc = ccc
            ),
            cr = calculateCR(
              ends        = consoleCombinedStat.ends,
              impressions = imps
            )
          )

gets reformatted to

          Stats(
            id = x.toInt,
            a  = calculateA(
            i   = i,
            rr  = rr,
            arr = arr
          ).toLong,
            c  = calculateC(
              c   = c,
              cc  = cc,
              ccc = ccc
            ),
            cr = calculateCR(
              ends        = consoleCombinedStat.ends,
              impressions = imps
            )
          )

(the bug is in the a = calculateA(..) block)

If the .toLong is not present, the indentation is correct. Something about adding a method call is interfering with the indentation level.

expected

l.filter(
  r contains _
).filter(
  r contains _
).toList

actual

l.filter(
  r contains _
).filter(
    r contains _
  ).toList

probably related to #25

private[foo] type Bar = String

becomes

private[foo]type Bar = String

which compiles but looks terrible.

It would be nice to have a config to align chained methods with the dot of the first call.

Instead of this:

Option(readLine).map(_.toLowerCase())
  .filter(l => l == "y" || l == "n")
  .map { case l => l == "y" }
  .getOrElse(readConfirmation(prompt))

The formatter could do this:

Option(readLine).map(_.toLowerCase())
                .filter(l => l == "y" || l == "n")
                .map { case l => l == "y" }
                .getOrElse(readConfirmation(prompt))

I have some code like this:

val s3Client = new AmazonS3Client()
val threadPool = Executors.newFixedThreadPool(settings.S3ThreadPoolSize).asInstanceOf[ThreadPoolExecutor]
val configuration = new TransferManagerConfiguration()
val transferManager = new TransferManager(s3Client, threadPool)

I wish I could have it formatted like this

val s3Client        = new AmazonS3Client()
val threadPool      = Executors.newFixedThreadPool(settings.S3ThreadPoolSize).asInstanceOf[ThreadPoolExecutor]
val configuration   = new TransferManagerConfiguration()
val transferManager = new TransferManager(s3Client, threadPool)

Not sure if I missed it or not... would be happy to help if you have some pointers on how to go about adding a new rule.

Thanks!

Hey,

If you look at these two lines (42-43), if there were a new line after Consumer.props(, like before, or the name = part before Some("consumer_" + params.queueParams.name), it would cause a java.lang.IllegalArgumentException: requirement failed error and stop formatting and compiling the code.
If you check out that repo at the referenced commit, you can reproduce it by reintroducing the previous state of the two lines i mentioned above.

The indentation is set to tabs, without that it works fine.

This is the place where the exception got raised: https://github.com/daniel-trinh/scalariform/blob/master/scalariform/src/main/scala/com/danieltrinh/scalariform/formatter/ScalaFormatter.scala#L185

When alignParameters is enabled, the colon between the name and type sometimes does not preserve the extra space after the type.

Failing test case:

  """def a(
    |  underscore_ : Int = 1,
    |  underscore2__ : String = "1"
    |)""" ==>
  """def a(
    |  underscore_ :   Int    = 1,
    |  underscore2__ : String = "1"
    |)"""

Currently, the above example gets reformatted as this:

def a(
  underscore_ :  Int    = 1,
  underscore2__ :String = "1"
)

Note the lack of space between the type and colon.