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.
In NetBeans 3.5 RC1 I have noticed with class variables (aka members) that code competion doesn't always work. What usually happens is I go into a newly opened (or unused for a while) editor window and: - type type the start of var name, _ (for _myClassVar) - hit ctrl-space, see code completion for a number of corba classes that start with an underscore, but none of my class vars - hit escape to get rid of the popup - hit ctrl-space again, and see the class vars At this point I see the vars until I leave that editor window for a while. This was noticed on a thread in nbusers.
I entered this with a relatively high priority since it is fairly repeatable and noticeable. As always feel free to adjust lower. :)
I can confirm this (on linux too) and it's annoying. You have to thit CTRL+SPACE twice to get the variable showing in the popup list.
It seems, it was hard reproducible random issues and now it is 100% reproducible. For all just defined variables is necessary to invoke CC action twice.
This is a problem of synchronization. This affects mostly private members. Code completion database contains by default classes and their members with default levels of parsing. It means there are only public and protected members. After completion is invoked the memory code completion database for actual class is refreshed with the private (and default) members info. Refreshing (parsing task) is asynchronous. The behaviour is following: 1. By completion invoking the search query is performed. 2. At the begining of querying, refresh (private members parsing) is triggered. 3. Before the refreshing has been finished a search query results are created with the obsolete members info. It means only public and protected members are shown in the completion. 4. Refreshing is finished. 5. During next completion invoking all members are available. I will try to fix this. If the fix will not be very risky I would like to integrate it to NB3.5, if not, I would propose to waive it.
fixed in [maintrunk] DIFF: http://editor.netbeans.org/source/browse/editor/src/org/netbeans/modules/editor/java/NbJavaSyntaxSupport.java.diff?r1=1.44&r2=1.45 The problem was caused by the bugfix of the issue #24441 (Refreshing of the class info was changed to asynchronous. ) The fix of this bug performs synchronous updating before asynchronous. The asynchronous updating is still needed for #24441. Honza, Mila, do you think this fix could be integrated into release35 or should I ask for a waiver?
Created attachment 10322 [details] A patch for release35
To patch this problem, please copy the attached java.jar patch to the <NB_Install_Dir>/modules/patches/org-netbeans-modules-editor/ folder.
I would propose to waive this bug for Nevada. Although the fix seems to be easy, there is potential risk of performance affecting. This should be tested properly. Please, use the attached patch to fix the problem. Thanks.
This problem also affects the retrieving the members of some private variable. private String s; void foo(){ s.| } Invoke the completion after "s.". It should show members of String. Then delete or comment s. (make source compilable) and save the document. Try to invoke the completion in the same place after "s." again. Completion is not shown even after several invocations. Document has to be modified to workaround this.
Updating the summary for the [completion] prefix.
Fixed also in Nevada Patch 1 and in Arrow.
The fix does not seem to work. The following is the reproducible case for the fix failure: - Create a variable 'String drv' in a java class file. - Go to one of the methods and type dr, press ctrl-space. Code completion works correctly and shows drv. - Introduce a nre String variable called 'drx'. - Type dr in one of the methods and press ctrl-space. Code completion automatically fills in drv. This is wrong; it should display both drv and drx. - Now close the source file and discard changes. - Open the file again. Go to a method, type dr, press ctrl-space. - Code completion displays both drv and drx!! This is wrong. drx is not a variable in the class anymore. The change was discarded but code completion has apparently not refreshed. Should this bug be reopened?
Reopening the bug as the code completion for class members still does not work correctly. The completion list is not refreshed and thus does not work on first invocation.
There are two problems you discribed: 1. Added new field is not displayed in completion. I think that the main problem here could be the fact that the source is not parseable - it means it contains errors at the moment of parsing.As you wrote you typed first field drv, then invoke completion for dr. It worked. Then you wrote a second variable drx - After that, the parser tried to parse a modified source. But it seems it failed on the line where 'dr' was typed. (The line where completion was tested) Because the parser failed, the variable info wasn't updated. And that's why only drv was in completion and drx was not detected. The second reason why this could happened is the issue #24441 There is synchronization problem between java parser and code completion. The problem appears if you invoke completion before java parser is finished (or even invoked) - i.e. type variable drv and didn't allow parser to be invoked (parser is triggered after 2 seconds of idle time by default) by immediate pressing an arrow keys to navigate the cursor at the place where is test string for variable drv. The source is parseable at this time. Test line looks something like dr|v = new String(); (| is a caret position where completion is checked) Variable drv is not in completion. Even after further invocations. You need to modify a source to workaround this problem. 2. Closing a modified file and discard changes. It is already known problem. The same problem affects annotations. Try to add some method at the end of source, create a breakpoint for that line (Shift+F8) and close file with discarding the changes. If you open the file again the breakpoint is placed at the end of file. It seems the main problem is that the source is not parsed during next opening. I created a new issue for that - issue #37301 against editor module for now. Although it could be java module problem. I am resolving this issue as fixed, because this issue solves a different problem.
> Then you wrote a second variable drx - After that, > the parser tried to parse a modified source. But it seems it failed on > the line where 'dr' was typed. (The line where completion was tested) I am not sure I agree with the above. The code completion will always be invoked on an incomplete (and thus unparsable) line but should still work. Even though this bug is related to two other bugs, namely, http://www.netbeans.org/issues/show_bug.cgi?id=37301 and http://www.netbeans.org/issues/show_bug.cgi?id=24441, I suggest that this bug is reopened. Once 37301 and 24441 are fixed, we can come back to this bug and verify that those fixes do indeed fix this issue and then close this issue. (QA can reopen the bug if they agree with my suggestion).
My understanding of (1) is that the parser database doesn't get updated between the points where the new member 'drx' is declared and the *immediately* following attempt to invoke the code completion. The fact that the parser fails to parse a modified (incomplete) file may be a technical limitation of current implementation. However, the users don't care, to them the code completion just doesn't work as expected. So I agree that this bug should remain open. Perhaps, with a lower priority since the previous fix helps to some degree. Reopening -> P3.
Code completion retrieves data from Java Source Hierarchy. If there is an error in source code - the source is not compilable, not parseable - then Java Source Hierarchy provides only data from last successful parsing. That is why code completion cannot display newly added fields, methods and other class members. I have created an enhancement against java module - issue #37417 and make this issue depending on that.
Let me comment this: The code completion will always be invoked on an incomplete (and thus unparsable) line but should still work. If the above would be the requirement then I can say for sure that we will never successfully fix this issue. It would require us to build a parser that would "understand" any (even seriously incomplete) input from the user. This is technically impossible. The minimum necessary requirements would include having a true incremental parser with superior error recovery and additional "guessing" logic for user's incomplete input. Moreover such logic can never be perfect. Instead IMHO we should define conditions under which the source should successfully be parsed or complementarily identify lexical and syntactic constructions that may legally break our parser. For example we can define that if the left and right braces do not match in the source document then the source is considered unparsable and the user cannot expect to see the last added variables, methods etc. until she fixes the problem. If we later find some of these constraints too limiting we may try to improve the parser in that direction. For example if we would have an incremental parser we could get rid of the non-matching braces problem into some degree because the incremental parser would know the last typed brace that has broken the balance.
I would like to summarize the current status of the bug: 1) once the modified source is closed without saving the changes the java module will now reparse the source and the completion will be updated. Thank to this the last complaint in Karthik's report from 2003-11-14 should now be resolved. 2) issue 24441 was fixed. The editor is now notified about finishing each parsing request which allows us to update the code completion database right at that time. The current behavior: Once the completion is invoked (automatically or by Ctrl+SPACE) the completion may display obsolete data in case there was e.g. a field added but the file was not yet reparsed by the java module's parser. Once the typing is stopped (for by default 2000ms) the java module reparses the document which notifies the completion which in turn updates the parser database by the new data. The next completion window opening/refreshing will use the most up-to-date data from the java parser. Still the completion is limited by the java module's java parser capabilities especially by its error-recovery in cases when the source is syntactically broken. Karthik, please decide whether the current behavior satisfies your requirements and this issue can be closed or whether it should remain open.
I tested the current behavior against the latest ide build. From a user perspective it is acceptable. However, I did notice a delay in the code completion when I tried removing variables. The deleted variables were still visible in the code completion box, after a small delay it was updated correctly. I guess this is the error recovery limitation mentioned in the bug.
The fix definitely improves the user experience. There are still two pending issues as commented by Miloslav. 1. Problems due to java parser's error handling limitations. This of course is a separate issue (37417). 2. The delay in communication between java parser and code completion leading to obsolete information in code completion. Since the delay is small (2000ms), I think this is acceptable. QA can close this bug if they agree. I suggest that a separate bug with a low priority be opened for the issue (2) above to ensure it is tracked.
Thanks for the updates. Petre F. and Honzo Ch. do you agree to close this issue and file a separate issue as Karthik requested? BTW I'm wondering whether we would be able to improve the user's experience by triggering an update of the content of an already opened completion window once the parser finishes reparse. Right now when an opened completion window gets refreshed (e.g. after typing a character or pressing right/left arrow) the selection index is reset to zero. If we would be able to implement retaining of the selected item in the completion window we could refresh the opened completion window upon reparse so the user would not be forced to refresh manually. On the other hand we would have to solve some problematic cases e.g. when the user selects an item that will no longer be there after the refresh. Of course that would be rare but it may happend. So this would definitely be an item for promoD but IMHO it might make sense. In parallel we should think about making the java reparsing more incremental e.g. reparsing just a changed method instead of the full source. That would allow us to shorten the time for auto reparsing or request the reparsing synchronously prior completion invocation.
Yes, I agree to close this issue. The reported issue (first comment) is now fixed. I tried open file and show CC dialog immediately. There are all class variables and methods.
I created new issue 40134 which describe the issue where CC dialog shows obsolete informations. Closing this issue as resolved fixed.
Verified