This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Thanks for a wonderful editor! I keep hitting an immensely annoying code completion issue that exists in at least RC1 and RC2 and I suggest it needs fixing before Netbeans 5.0 is released. My code completion options are "Auto Popup Completion Window"; DO NOT "Insert Single Proposal Automatically"; "Case Sensitive Code Completion"; "Show Deprecated Members in Code Completion"; and DO NOT "Insert Closing Brackets Automatically". Here's how to reproduce the issue. First create this class: public class BrokenCodeCompletion { public static int nameOfStaticField=0; public void name() { } } And a class to test out code completion: public class BrokenCodeCompletionTest { public void test() { BrokenCodeCompletion cls=new BrokenCodeCompletion(); cls // ^start typing here } } After cls type .name( When I do this the output becomes .nameOfStaticField( While the substitution is clearly incorrect also note that this static field should not have appeared in the code completion popup (cls. is dispatch upon an instance of a class rather than the potential namespace of a static field).
This report is partialy duplicate of issue #62953 and partialy describes the way how current infrastructure is designed. It's indeed annoying but according to our Bug Priority Guidelines (see http://qa.netbeans.org/processes/bug_priority_guidelines.html) it's P3. Thanks for understanding.
There are two problems mentioned here: 1. Code completion offers a static field in a place where it should not. I am not able to reproduce this problem on a second class - I do not get the static field as an option in code completion. I can see the problem if I put this code into the same class, but in this case the code doesn't make sense (you can't have two classes in one class). For inner classes it works as expected. 2. As for the second problem with automatic filling, it's known. The issue is that we added automatic filling in of options in code completion by pressing chars like (, ;, comma, etc. So in this situation you have two options: ----------------------- |cls.nameofstaticfield| |cls.name | When the first option is selected and you press ( right after typing name, the first option gets prefilled. To avoid this, you need to scroll to the second option and then it gets filled in properly. I know this is annoying but it is currently designed this way and we should improve it for the next release. Note that it only occurs in the situation when there are options which start with the same String (e.g. "name" here) and the option you want to choose is not in the first place. Decreasing priority to P3 as this was not agreed to be a stopper for 5.0 release. Needs to be addressed in the next release.
This is input data corruption. Perfectly legal code is broken while it is simply typed in. This is no different than a calculator corrupting numbers as they are typed in or a word processor corrupting letters as they are typed in. I type in the name of a method( and it is replaced with irrelevant broken code. I've just grepped one of my packages and this breaks the typing in of one method across 137 lines and multiple times per line. Here's an example line: env.stack(toStack).pushObj(env.stack(stack).popObj()) [with code completion enabled I can't type stack( because a stackLogicalArray field exists within the same class] Perhaps there is a way to turn off all completion while keeping the popup information? While I can turn off code completion (and in fact I had to) I again suggest you should not go gold with this bug.
I asked the developers to evaluate this issue to see if there's something we can do for 5.0.
Created attachment 28553 [details] Possible fix
The fix eliminates filling of the completion item's text upon typing of '(' in case the item is not a callable feature i.e. either constructor or method. So the field completion items should no longer be completed by '(' which should eliminate the described problem. I have integrated the fix into the main trunk: Checking in src/org/netbeans/modules/editor/java/NbJMIResultItem.java; /cvs/java/editor/src/org/netbeans/modules/editor/java/NbJMIResultItem.java,v <-- NbJMIResultItem.java new revision: 1.43; previous revision: 1.42 The fix should be reasonably safe but I cannot decide whether it will finally go into 5.0 or not as it's very late in the release cycle so now it's mainly up to Quality engineering (means restarting of test cycles etc. so it's a tough decision). Anyway there may be updates released for 5.0 that can contain this fix.
Many thanks for comprehensively fixing this bug and incorporating the fix into release 5.0!