Scala type completions should be sorted differently
Unfortunately, Scala type completions are often sorted in a way that makes it much harder than it should be to select the type one normally wants. Here is an example:
Here is another example:
The most interesting types, that is
I propose to implement the following ordering (considering that the completion is invoked in
1. types close to
2. types below
3. all other types, giving priority to non deeply nested types (that means that
scala.concurrent.Future
, which is the wanted type in 99% percent of all cases, is only at the third position.Here is another example:
The most interesting types, that is
java.net.URI
and akka.http.scaladsl.model.Uri
are listed far away from the beginning of the list.I propose to implement the following ordering (considering that the completion is invoked in
my.org.project.sub.pkg.some.where
):1. types close to
my.org.project.sub.pkg.some.where
, that is for example types from my.org.project.sub.pkg
or my.org.project.sub.pkg.some.where.nested.deeper
2. types below
scala
like scala.util.Try
3. all other types, giving priority to non deeply nested types (that means that
org.bson.Document
would come before gate.creole.annic.apache.lucene.document.Document
) and types that contain the word scala
(so that org.mongodb.scala.bson.collection.immutable.Document
comes before gate.creole.annic.apache.lucene.document.Document
and akka.stream.scaladsl.Flow
before akka.stream.javadsl.Flow
.
Leave a comment
Limit completion proposal relevance to 100
This limit makes sense because template proposals normally get a relevance of
90. Internally the relevance is calculated on a scale of 0 to 1000 though, to
be more flexible.
Fix #1002686
Branch: master
Commit: scala-ide:1d9c04e9ff
This limit makes sense because template proposals normally get a relevance of
90. Internally the relevance is calculated on a scale of 0 to 1000 though, to
be more flexible.
Fix #1002686
Branch: master
Commit: scala-ide:1d9c04e9ff