Community
Participate
Working Groups
Take the following example package app; import java.io.File; import java.nio.file.Paths; import java.util.Set; public class HelloTest { private File file; @org.junit.Test public void testHello() { Set<String> strings; this.file = new File(""); Paths } } Now make sure your imports are collapase, and then remove the "Paths" reference and organize imports. The source code rendering is not done properly to reflect the changes. This happens on when codeminings are available. I will attache a video which shows it in action
Created attachment 286179 [details] rendering issue 1
Created attachment 286180 [details] rendering issue 2
Created attachment 286181 [details] codemining rendering issue screencast
Is there any activity on this Bug, right now on 4.20 having code minings on new files cause code mining and editor unusable.
(In reply to Gayan Perera from comment #4) > Is there any activity on this Bug, right now on 4.20 having code minings on > new files cause code mining and editor unusable. Not from my side. While I can reproduce some issues wth code minings locally, the ones I see are not causing loss as you experience on macOS. I guess this issue is probably caused by some lower-level bug in macOS rendering. I usually can't fix macOS specific things.
Even though i recorded in MacOS, this happens on Windows 10 as well. This is prominent when the file is small, fit into the editor view port without needing to scroll.
New finding: This only happens for only for LineHeaderCodeMining implementations. Seems like the problem is with the reconcilers. May be the code mining reconciler is executed before source reconciler (just assuming) ?
I think I found the problem. Seems like this is cause by the NPE in one of annotation marker which cause the Java Reconciler to throw errors. I will do some testing without that Marker and close this issue.
I retested and found that the Marker issue not causing this. I have more data now. Create simple project with this class package workbench; public class TestCase { public void testFoo() { new TestCase(); } public void testBoo() { testFoo(); } } Enable reference codemining for Type, Field and Method in JDT preferences. Now make a syntax error at testFoo method declaration by changing the code like public void testFoo(Li) Now you will have the rendering issues in JDT Editor.
Created attachment 286333 [details] simple test
The problem seems to be that the first cycle of codemining painting is not down due to the minings are not resolved, then later after the source code/semantic painter has paint the styling of the source, the minings will get redrawn, but the source code is not repainted to adjust the mining. I think its probably the SemanticHighlightingReconciler which doesn't run again after code minings are drawn
@Noopur has there any JDT UI changes recently which can cause this ?
Something i found out is if i execute getViewer().invalidateTextPresentation(); at org.eclipse.jface.internal.text.codemining.CodeMiningLineHeaderAnnotation.draw(GC, StyledText, int, int, Color, int, int) after minings are drawn and when a mining is not drawn at all fix the issue, but it puts the editor to a redraw loop. What could be the issue which is getting fixed by invalidateTextPresentation ?
I tried with the modified CodeMiningDemo to hide minings when there is no refCount and i can see the same problem there as well.
The problems start with Bug569550 and it is their through the fixes done in Bug 570208,Bug 570342. The problem is in SWT StyledText class in LineVerticalIndent feature.
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/180382
I did a very novice patch which solves the issue described here, but i'm pretty sure i'm not fixing using the optimum solution. But i will use this patch for now to fix my eclipse installation until we have a good fix.
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/180382 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=0e5010e86bd35a230fd68999168e717221d357ec
Thanks Gayan! Anyone feel free to reopen if this fix is not sufficient. If no-one sees the issue before M1, we'll assume it's verified/fixed.
