Code completion is case insensitive (behaviour different from Eclipse Java support)

[scabug]

Code completion in the plugin is completely case-insensitive. This doesn't match Eclipse's behaviour in Java files where the order on the entries in the popup is case sensitive. i.e. the popup contains the same items regardless of case but the lower case items are at the top if the item being completed is lower case and vice versa.

The current behaviour makes code completion much less useful for completing lower case variable and method names because there are always loads of upper case class names to scroll past. In many cases it's just quicker to type the whole word.

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-1643?orig=1 Reporter: Chris Kent (cjkent)

[scabug]

@milessabin said: Fixed in r17096. Code completion is now reusing the underlying JDT implementation so behaviour should be the same as for Java.

[scabug]

@ijuma said: I don't think this is fixed. Tested with the nightly from this morning. Starting from:

import java.io._

class Foo {

  var map: Map[Int, Int] = _

  def bar(list: List[String]) {
    m
  }
}

Press ctrl+space with the cursor after m and Map is suggested before Map.

The JDT suggests map before Map with the equivalent Java file.

[scabug]

@ijuma said:

Press ctrl+space with the cursor after m and Map is suggested before Map.

I meant Map is suggested before map.

[scabug]

@milessabin said: Actually, it has to be doing exactly what Java is doing because it's using the same code now. The problem is that it's maybe not quite what you were expecting here: if you notice, the icon next to Map in the list of auto-complete suggestions indicates that it's a val and it's type is scala.collection.immutable.Map.type which is the singleton type of the Map object.

So what's going on is that the JDT is treating both map and the Map object as completion candidates and as belonging to the same category (ie. of values). It's then sorting them internally to that category in the way it deems most appropriate, which is presumably not what you expected.

Have a check whether or not this explanation tallies with your experiences and let me know.

[scabug]

@ijuma said: I think you're right. Is there something we can do about it? And if there is, shall we re-use this issue or file a separate enhancement?

[scabug]

@milessabin said: I think it ought to be a separate enhancement. To be honest I'm not sure I know what better behaviour would be so it might be an idea to canvas for proposals on the lists.

FWIW, changing the behaviour using AspectJ should be fairly straightforward, so it might be an excellent job for someone who wanted to get their feet wet and try out the new approach to JDT integration.

[scabug]

@ijuma said: Ok, I filed ticket #1715 with some additional information to track this.