Community
Participate
Working Groups
I20061030-1704 Given: package test; public class E1 { void m() { variable = 10; System.out.println(v); } } 1. Set cursor after 'v' in println 2. Ctrl-Space Is: variable is not proposed Should: variable should be proposed
I agree that this would be a nice feature. Erich mentioned this yesterday as well. The current support only shows proposals for the local variable declaration. Moving to JDT Core for comment: maybe the new support can be leveraged to support this scenario as well.
Will investigate performance ramifications. Could be behavior conditionned by a new option (off by default).
Created attachment 60060 [details] Proposed fix
The behavior added by this patch is the following. All unresolved simple names are proposed as possible local variable. -------------------------- package test; public class E1 { void m() { variable = 10; System.out.println(v); } } //'variable' is proposed as a possible local variable. -------------------------- These simple names are searched between the start of the most enclosing method and the completion location -------------------------- package test; public class E1 { void m() { variable1 = 10; new Object() { void m2() { variable2 = 10; System.out.println(v); } } variable3 = 10; } } //'variable1' and 'variable2' are proposed but not 'variable3' -------------------------- The relevance of these possible local variables is lesser than declared local variables -------------------------- package test; public class E1 { void m() { variable1 = 10; int variable2 = 10; System.out.println(v); } } //the relevance of 'variable2' is higher than relevance of 'variable1' -------------------------- The completion engine only searches unresolved names inside the previous 100 lines of code to avoid performance problem when the code is too big. The performance of completion engine can be between 0% and 50% slower than before when completing a simple name. But the full time is always very short even when it is 50% slower. So add an option isn't necessary because performances are still good. The computing of type proposals has more impact on performance than this new behavior. What do you think about this proposal?
I think about some possible variation of behavior: 1) Propose these proposals only if there is no other proposal. Unresolved names would be only spare proposals 2) Propose these proposals only if there is no other proposal or if there is more than two other proposals. With this variation there is no impact for users who like insert single proposal automatically. 3) Add a JavaCore options to enable/disable this behavior Personally i don't find these variations useful but maybe i am wrong.
>These simple names are searched between the start of the most enclosing method I would prefer to scan above and below (we could then reduce it to 50 lines each). That way we have a more coherent story. I agree with you: the last variations would just be confusing since they make code assist less predictable. Since we didn't add a preference for the declaration proposal we won't need one for this as well.
Created attachment 60155 [details] Better fix Unresolved names are searched below and above the completion location with this patch
Released for 3.3M6 Tests added CompletionTests#testNameWithUnresolvedReferences001() -> testNameWithUnresolvedReferences0010() CompletionTests_1_5#testNameWithUnresolvedReferences001() -> testNameWithUnresolvedReferences003() Updated all model completion tests caused by addition of R_RESOLVED
Verified for 3.3 M6 using build I20070319-1335. The implemented behavior is the one with a search above and below the insertion point. Two remarks: - using the original test case, the 'variable' proposal comes after pages of class names (in my workspace); completing 'var' still yields many ones; if you do that on the latest test case of comment #4, the class names separate variable2 (top proposal) from variable1 (near bottom proposal); I am not sure raising the relevance of variable1 would be appropriate, but I felt it looked odd; - I also get 'void' as a proposal, which I believe is wrong; please let me know if it is expected or if I should enter a new bug (my search on 'void assist' did not yield related bugs).
