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.
This is in regard to a user issue and feedback from nbusers: I was looking at this further, and it seems to me that part of the issue is that editor hints code fixes should automatically update the errors listed for the document which they fix, unless they already are... I noticed though that on my One laptop with Dual Core Intel, 2GB, OpenSuSE10.2, NB6 daily it is very fast, and when I tell it to add the throws clause for a method it is almost instantaneously removed from the error bard...in a 2500+ line file...not that it won't ever be slow. On my other system, Dual Core, 2GB, Windows XP Pro (different laptop vendor...Dell actually), NB5.5 the same process in a 1700+ line file it seems to take longer (2 or 3 seconds before the error annotation goes away). If the annotations are not being removed before the parse (not sure on the threading and events here) then they could be removed much faster. The parser will take a couple of seconds at best I think depending on the file size. When typing to fix an error it doesn't seem such an issue usually because of the way we register things as we type though I have noticed that when I am typing at times the parser will not be run until I am finished typing all together, so the changes seem to take longer to take, and it seems to be related to when background parsing takes place. There may be some tricks the devs could use to make that better too, but certainly editor hint fixes could be given an ability to hook into the error system and remove the specific fixed issue before parsing ever takes place...I think. I didn't know where to actually put this...wasn't sure if it is MIME type specific or what. I figure if the editor support provides the base API to remove a given annotation directly from an editor hint fix then it would be a good start. I noticed there is the class org.netbeans.editor.Annotations which seemingly supports this...just not sure if it is being used or if it is actually what would do this.
My use case was using the editor Anotations to add "throws SomeException" to method definition. There were 2 Exceptions to add and as Ctrl+Enter + Enter is fast to do, when I did Ctrl+Enter second time, the first (already "fixed") Exception still showed in the list. Thanks Wade for filing this and doing deeper analysis.
Well, I am not sure against which version is the complaint meant: it says that NB6.0 removes the error almost instantly, and that NB5.5 is slow in this regard - I do not think we can (now) do anything in NB5.5 for this. What could be done (for NB6.0, if time permits), is that the Editor Hints API could, when a fix is implemented, remove the corresponding error. Or all errors on the corresponding line - might be a bit trickier though, and also more confusing. Might need some experiments. I do not think that removing annotations before the parser starts is a good idea - the whole file might flicker (the errors would be removed, the non-fixed ones would be put back, and so on).
Ok, here is how I understand the report, please correct me if I am wrong. There is nothing we can do for 5.5.x, the complaint is about hints annotations not being removed fast enough after a users chooses to apply the suggested fix. As with any performance issue we need some serious numbers first in order to be able to start optimizing things. From what jlahoda says I understand that there is no obvious problem in the code that we could easily fix.
Other users have said the same about 6.0 in the lists as I have mentioned about 5.5. If the system isn't updating the errors directly, and only relying on parsing, then it will inevitably have different times where lag will be greater as it will be more dependent upon the CPU and other resources for performance. If you have an editor hint for a code fix it shouldn't create error prone code, so if it removes the error it should not come back, and as a user can only make a real action at a time, we really don't need to parse the document again on such a change. We can save some resources [CPU, memory, and disk resources here]. If there is another hint or error for the same line then this one should still be visible and shouldn't be removed, I imagine this built into the API, so I don't see why it has to cause flashing of the error marker if both errors would have caused painting in the same region. Think of it as a stack of cards or layers where you draw 3 red squares on top of each other. You pick one off and the color doesn't change. If each annotation isn't asked to paint itself and another API or class does the painting based on whether an icon or some graphics should be painted at point A or B or not then it should know whether there are other objects (in this case annotations) that the given area or line will still be painted over and should update accordingly and not remove the drawing and graphics if it still needs them.
As I said, we can remove the one annotation that corresponds to fix that has been implemented. The paragraph about flickering was more about removing all error annotations from the whole file, which I though you were proposing (but reading your comment again, I probably misunderstood this).
Sorry if I wasn't more clear on my initial post. Looks like we're on the same page.
Resolving all issues with milestone "future" as LATER. If you feel strongly that it should be implemented please reopen and set the target milestone to "next".
NetBeans.org Migration: changing resolution from LATER to WONTFIX