Community
Participate
Working Groups
Applies to: Eclipse SDK, Version: 3.3.0, Build id: I20070625-1500 Java SDK 1.6.0 Other version: similar results are obtained with Eclipse Platform Version: 3.0.0 Build id: 200406251208 and J2RE 1.4.2 Overview Description: Contest assist proposals favor classes from com.* packages instead of classes from local project or standard java.* packages. Sometimes many keystrokes are required in order to get the java.* class. Special setup: "Sorting and filtering configuration" under Window|Preferences|Java|Editor|Content Assist selected: * Sort proposals by relevance checked: * Hide proposals not visible in the invocation context * Show camel case matches * Hide forbidden references * Hide discouraged references * Hide deprecated references Steps to Reproduce: 1) Open any .java file 2) Write the first letters of a class name (such as "Matc" or "Patt"). 3) Press CTRL+space Note 1: after choosing some classes the order is modified (I guess it is because "sort by relevance"). Note 2: In the step 2, other prefixes may be used. "Matc" and "Patt" are given as an example. Actual Results: Autocompletion for "Matc" prefix yields 5 results from com.sun.org.apache and 2 results from java.util.regex. The first results are: com.sun.org.apache.xerces.internal.impl.xpath.regex.Match; com.sun.org.apache.xerces.internal.impl.xs.identity.Selector.Matcher java.util.regex.Matcher com.sun.org.apache.xalan.internal.xsltc.compiler.util.MatchGenerator Expected Results: Classes from java.* and javax.* packages are more likely to be used. I would have expected java classes listed first or (at least) and option to configure packages preferences in order to instruct the UI to show classes from java.* and javax.* before classes from com.* Were java.util.regex.Matcher listed first, I would have been able to press CTRL+SPACE ENTER in order to select it.
I don't think we can make assumptions what types are more important for the user. We have to show you all available types and have to put the most specific match first. In your example, 'Matc': 'Match' is more specific as 'Matcher' What we already have is: - You can specify type filters on 'Java > Appearance > Type Filters' and filter all types from packages like com.sun - We have a type usage history, so as soon as you chose a type, it will get a higher relevance next time. But again, this only matters when you have two types of the exact same name (two classes of the name 'Matcher') Does that help? Moving to jdt.core as they are computing the relevances.
(In reply to comment #1) > I don't think we can make assumptions what types are more important for the > user. Good point, alphabetic ordering is consistent. > We have to show you all available types and have to put the most specific match > first. > In your example, 'Matc': > 'Match' is more specific as 'Matcher' Yes, but (in my opinion) users should be allowed to modify such order not only by filtering. For instance, they might provide a list of prefixes to be listed first, and a list of prefixes to be listed last. Ties among them might be resolved by current relevance sorting. Note that I do not request any particular implementation. I'm only thinking aloud and trying to figure out a solution that: a) Be simple to configure. b) Provide default ordering if no customization is done. c) Allow users to specify their preferences. > What we already have is: > - You can specify type filters on 'Java > Appearance > Type Filters' and filter all types from packages like com.sun I was not aware of this option. Perhaps it may be linked from 'Java > Editor > Content Assist'. > - We have a type usage history, so as soon as you chose a type, it will get a > higher relevance next time. But again, this only matters when you have two > types of the exact same name (two classes of the name 'Matcher') That is a nice feature. > Does that help? Sure it does!
(In reply to comment #2) > Yes, but (in my opinion) users should be allowed to modify such order not only > by filtering. For instance, they might provide a list of prefixes to be listed > first, and a list of prefixes to be listed last. Ties among them might be > resolved by current relevance sorting. I like this idea. Another possibility (but complicated from an implementation standpoint) would be for the context assist to glean, for example, that if your class isn't importing org.apache classes, but is importing java.util, to suggest matches against classes in java.util first. In my experience, I'm much more likely to import more things from libraries and packages I'm already importing that from new ones. Another use case that always gets me when I use context assist and often mess up: I'm using SWT on my project so every single time I'm writing a new UI class I want all widgets (or related objects) to come from org.eclipse.swt and never javax.swing. Of course, I can also just initially add an import org.eclipse.swt.* in my class to get around most of this and remember not to use "Organize Imports" until I think I'm done.
I also think this would be very useful, for example to make appear first the classes inside the current Workspace (usually, these are the ones you want to use more likely). The last proposal seems pretty difficult to implement, although. Regards
The lack of this feature is an annoyance. Especially in the case where you're trying to quick-fix a class which the compiler should be able to detect the type of. E.g. Foo foo = something.getBar().getFoo(); where Foo is a compile error because it's needed as an import, but the rest of the statement is fine. Assuming Foo is a commonly used classname, the quick-fix ordering on Foo often has it at the end of the list of suggested imports. It should be first in the list because the compiler knows the return type of getFoo()
