Community
Participate
Working Groups
In the following code ... public class HelloWorld { private int i = 0; public static void main(String[] args) { HelloWorld helloWorld = new HelloWorld(); hell-> Hitting cntrl-space at the arrow brings up a list of choices ... which includes HelloWorld, the class and the helloWorld variable, but since the text is "hell", with a lowercase "H", it should just directly insert helloWorld. If this is considered a feature, then provide an option to switch between the two cases.
David - please check the ordering of the various proposals. If the case match doesn't come first, then this is a sorting issue (UI heuristic would be wrong).
The current correct behavior is to propose two completions : 'helloWorld' and 'HelloWorld'. And 'helloWorld' must be the first proposal. Brett - with your test case the proposal are in the correct order for me ('helloWorld' is the first proposal). Could you give me more details to reproduce the problem ?
Your comment is the same for me. Both helloWorld and HelloWorld appear. My proposed defect claims that it should just complete with helloWorld and not popup the list. Personally I think it is incorrect to provide both, especially since my goal with completions is to enter code as fast as possible and I see the popup window as a interuption in that process. I see helloWorld and HelloWorld as mutually exclusive and I don't think they should appear in the same list.
The current behavior is the expected behavior. So, to solve the problem an option must be added. When the option is disabled all the completions are proposed. When the option is enabled only the most relevant completions are proposed. If this option is added to JDT/Core then template completion can not be filtered. Perhaps it should be better to add this option in JDT/UI side. Move to JDT/UI for comment.
You can't give one of the two options a higher weight and filter the other one out. Code assist was always case-insensitive. Now imagine with the option being enabled you would want to write: HelloWorld helloWorld = new HelloWorld(); HelloWorld helloWorld2 = new HelloWorld(); and currently in the editor it looks like: HelloWorld helloWorld = new HelloWorld(); hell-> I would end up with 'helloWorld' I would suggest another fix for the problem: add 'Case Sensitive' option. If this is enabled the suggested proposals honor capitalization.
Code assist is case in-insentive but relevance of a proposal is higher when case match. So the filtering of proposals is possible. Your suggestion is to filter proposals by case matching. My suggestion is to filter proposals by relevance.
>When the option is enabled only the most relevant completions are >proposed. We could do this but I fear that lots of time we would only get 1 or 2 results. Currently JDT Core does not specify at all what values the relevance can be except that they are int and that we can only use them for comparison. If we introduce such an option we should be able to give some threshold but that is only possible if the relevance value has a higher level definition or if relevance levels or categories exist. Adding a case-sensitive option is not desirable since this means you always have to enter capital letters for types. Brett, can you please comment.
*** Bug 33236 has been marked as a duplicate of this bug. ***
I completly understand why your fears, but this is what Idea does, and it does a real good job at it. Makes it a whole bunch eaiser ... and never is really a problem.
Using eclipse more and more, I can't stress the desire to have a case senstitive option / relevance option enough. Here is an example: protected void createTableButtonBar(Composite parent) { pa[Ctrl-Space] Question, what do you think appears ... a popup list with 50! items to choose from (and 49 of them start with a capital P!) Fortunately "parent" is the first choice. But this means that I almost always hit ctrl-space, followed by an enter! I find this that is much less desirable then when I am interested in a class name having to type a cap. At the very least make it an option so everyone can choose how they want it to work ... so in my case when I hit control space in example above, it would automatically give fill in "parent"!
*** Bug 46426 has been marked as a duplicate of this bug. ***
I totally agree that an option for case sensitivity would be really great. Moreover, it would avoid all those two-lower-case-letters classes that mostly com from com.sun.rasign that always fill the content assist box. I use the "a" prefix for function arguments, and more often thatn not the first choices are one of these funcky classes.
Stupid me, the funky classes are lower case, so my "a" prefix will always trigger them. Bug 50135 proposes a solution to this problem. I stay convinced however that adding an option to toggle case sensitivity would be great.
Why not just add another keystroke in addition to Ctrl-Space that makes the most relevant completion if possible (i.e., a single possible completion is more relevant than all others), or pops up the same list of available completions, sorted by relevance, if not?
One of the goals of allowing content assist to be case sensitive is also to reduce the list of choices. I think that an "I feel lucky" keystroke is not really needed, I mean typing Ctrl+space then enter is not necessarily more difficult that a single keystroke. However I don't see any inconvenient to such an additional keystroke. Back to the topic of case sensitivity, there could be three options : -case insensitive -case sensitive for 1st letter -case sensitive for the whole word. I'm not inventing anything, its the way IntellJ IDEA works. I always used the 1st letter case sensitive option, and it felt much better than Eclipse's case insensitiveness.
John, adding a new command might be a good solution. I couldn't quite follow your other comments. The proposals are already sorted by relevance and there's a preference which allows to automatically inserts the proposal if there's only one.
I was just rementioning ordering by relevance to make the proposal complete, knowing that's how it currently works. I am, however, making a distinction between a single available proposal and a single proposal with the highest relevance. Using Brett's example in comment #10, the current functionality would only auto-complete "pa" with "parent" if "parent" was the only available proposal, which is not the case here. What I'm suggesting is that this new keystroke would auto-complete with "parent" because it's the single proposal with a higher relevance than the other 49 available proposals. Thus, Brett would gain the capability he's looking for to get "parent" filled in with a single keystroke.
(In reply to comment #0) > HelloWorld helloWorld = new HelloWorld(); > hell-> The question is - should eclipse help me more if I specify the case correctly ? - or should it not punish me too much if I make a mistake in specifying the case ? Now that I think about it, I have always found it mildly annoying that content assist shows me a gazzillion types when I am looking for a local variable. I am inclined towards the first option - eclipse should assume that I know what I am doing and behave accordingly. (In reply to comment #5) > I would suggest another fix for the problem: add 'Case Sensitive' option. If > this is enabled the suggested proposals honor capitalization. +1
See also bug 251865.
