daniel-trinh / scalariform Goto Github PK
View Code? Open in Web Editor NEWThis project forked from scala-ide/scalariform
Scala source code formatter
Home Page: http://mdr.github.com/scalariform/
License: MIT License
This project forked from scala-ide/scalariform
Scala source code formatter
Home Page: http://mdr.github.com/scalariform/
License: MIT License
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
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.
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.
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?
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.
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)
)
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 would be great to have an InsertNewlineAtEof
preference to go along with scalastyle's NewLineAtEofChecker
.
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.
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
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
)
)
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.
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.
It could help to strip down useless blank lines, I usually set it to 1
in IntelliJ.
<maxBlankLines>1</maxBlankLines>
com.danieltrinh
to org.scalariform
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)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.
re the discussion at scala-ide#130
Please could you clarify the following?
mdr
on 2013-04-24mdr
original?mdr
thinks about the project?Thanks,
Rich
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
expected
l.filter(
r contains _
).filter(
r contains _
).toList
actual
l.filter(
r contains _
).filter(
r contains _
).toList
probably related to #25
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'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
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?
private[foo] type Bar = String
becomes
private[foo]type Bar = String
which compiles but looks terrible.
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 {
...
}
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!
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"
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
)
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.
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.
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.
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?
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 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
I think we should copy open issue from orginal scalariform repository here and inform submitters about it.
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>
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.
It would be neat to be able to brew install scalariform
to use the standalone cli jar on OSX.
Things to do:
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...?
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.
see scala-ide#37 and scala-ide#51
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.
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.
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))
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.
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]
)
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.