Community
Participate
Working Groups
Created attachment 276369 [details] Screenshot naive approach How to create code minings at the end of the line With eclipse 2018-09+ its no longer possible to have code minings with position length 0. i want to create minings at the end of a line. here is a very naive impl public class LineEndCodeMiningProvider extends AbstractCodeMiningProvider { @Override public CompletableFuture<List<? extends ICodeMining>> provideCodeMinings(ITextViewer viewer, IProgressMonitor monitor) { return CompletableFuture.supplyAsync(() -> { System.err.println("mimimi"); IDocument document = viewer.getDocument(); int numberOfLines = document.getNumberOfLines(); List<ICodeMining> result = new ArrayList<>(); for (int i=0; i<numberOfLines;i++) { try { IRegion lineInformation = document.getLineInformation(i); Position position = new Position(lineInformation.getOffset() + lineInformation.getLength(), 1); LineContentCodeMining e = new LineContentCodeMining(position, this) { @Override protected CompletableFuture<Void> doResolve(ITextViewer viewer, IProgressMonitor monitor) { return CompletableFuture.runAsync(() -> { this.setLabel("error"); }); } }; result.add(e); } catch (BadLocationException e) { e.printStackTrace(); } } return result; }); } } but this does not work since the result looks like attached. If i move the mining one position to the left it does not work neither cause then it would be drawn in the middle of the text. Did i overlooks something or is this a bug. Thanks
@Christian, I have manage this case in JDT CodeMinjing too (to draw end statement, see at https://github.com/angelozerr/jdt-codemining/blob/master/org.eclipse.jdt.codemining/src/org/eclipse/jdt/experimental/ui/javaeditor/codemining/endstatement/EndStatementCodeMining.java#L49) The only NOT cleaned solution that I have found is to add a space before the label. In your case: ----------------------------- this.setLabel(" error"); ----------------------------- should work. To be honnest with you, I wanted this feature, but I have not worked a lot to improve codemining. Any patch are welcome if you find a better solution.
New Gerrit change created: https://git.eclipse.org/r/132691
@Mickael, please review my gerrit patch https://git.eclipse.org/r/#/c/132691/ This gerrit patch avoid using GlyphMetrics#width when line content annotation is drawn at the end of the line. It fixes 2 issues: * you don't need to add an extra space to draw teh mining (original issue) * when you click on the right of the last character of the line, it doesn't execute the mining. You can test my gerrit patch with JDT CodeMining by activating "Show End Statement" an dwrite in your Java Editor a code like --------------------------------- if (true) { } --------------------------------- It should show the following mining: --------------------------------- if (true) { } [// -> true] --------------------------------- and if you click on the right of '}' you could set the cursor without executing the mining (which set the cursor on the if statement).
Gerrit change https://git.eclipse.org/r/132691 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=0cbe3ef0a78e36bccb3a9f2fd90594e87f4896b5
Thanks Angelo!
Thanks @Mickael!
I reopen it because I have introduced a bug -(
New Gerrit change created: https://git.eclipse.org/r/132702
Please review my gerrit patch please. I have forgotten the case where the editor doesn't update the region where mining must be drawn (clipping check). As StyleRange is not set in this case, we must redraw the regions if gc clipping doesn't contains the mining to draw. Sorry @Mickael for the introduced bug -(
It was an error. Please review my gerrit patch.
Gerrit change https://git.eclipse.org/r/132702 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=66e22caacafdfe48f7561114f1ae7c347fc0079c
Find a new bug again when there are 2 en statement to draw.there are infinite redraw.clipping check is a bad idea. I must fix That.
(In reply to Angelo ZERR from comment #12) > Find a new bug again when there are 2 en statement to draw.there are > infinite redraw.clipping check is a bad idea. I must fix That. Would be great if you manage to add automated tests for those cases by the way.
This is very likely to miss 4.10.M3 and isn't too critical for further work regarding code-mining. Retargetting to 4.10.RC1.
New Gerrit change created: https://git.eclipse.org/r/132732
New Gerrit change created: https://git.eclipse.org/r/132733
@Mickael please review https://git.eclipse.org/r/132733 which fixes freeze of code mining when it is at the end of line. IMHO I think this fix is very important. > Would be great if you manage to add automated tests for those cases by the way. I agree with you, we need tests for code mining, but it's so hard to test it.
(In reply to Angelo ZERR from comment #17) > @Mickael please review https://git.eclipse.org/r/132733 which fixes freeze > of code mining when it is at the end of line. IMHO I think this fix is very > important. I'll have a look right now, but we won't be able to merge it before Friday since we're in a Freeze period for 4.10.M3.
(In reply to Angelo ZERR from comment #17) > I agree with you, we need tests for code mining, but it's so hard to test it. Please at least make sure one example covers those tricky cases.
Mass change, please reset target if you still planning to fix this for 4.11.
I'll try that for 4.13, as I think we have some interesting cases for Code Minings that require it.
Mickael 4.12 is long gone. What's the status here?
(In reply to Dani Megert from comment #22) > Mickael 4.12 is long gone. What's the status here? I've removed the target as I do not want to see open 4.12 bugs.
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/190503
New Gerrit change created: https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/190504
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/190503 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=f3a0c35e22709c8761350e561ed8d9e85bb642c8
Gerrit change https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/190504 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=804b7656db7ed9dc6d00b9ee752c00222f364b91
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/190710
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/190710 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=15d09249911dd8052192e2d146a5961dd5391ff9
Doesn't work for \r\n line endings.
(In reply to Mickael Istria from comment #30) > Doesn't work for \r\n line endings. I see it is reopened, but looking into the code I can't understand how that is supposed to work, it doesn't look like a new line issue. org.eclipse.jface.text.source.inlined.InlinedAnnotationDrawingStrategy.drawAfterLine(LineContentAnnotation, GC, StyledText, int, int, Color) is always called with gc == null from the related code and isn't doing anything because of that: at org.eclipse.jface.text.source.inlined.InlinedAnnotationDrawingStrategy.drawAfterLine(InlinedAnnotationDrawingStrategy.java:140) at org.eclipse.jface.text.source.inlined.InlinedAnnotationDrawingStrategy.draw(InlinedAnnotationDrawingStrategy.java:130) at org.eclipse.jface.text.source.inlined.InlinedAnnotationDrawingStrategy.draw(InlinedAnnotationDrawingStrategy.java:61) at org.eclipse.jface.text.source.inlined.AbstractInlinedAnnotation.lambda$0(AbstractInlinedAnnotation.java:131) at org.eclipse.jface.text.source.inlined.InlinedAnnotationSupport.lambda$0(InlinedAnnotationSupport.java:573) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:40) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:185) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4035)
(In reply to Andrey Loskutov from comment #31) > I see it is reopened, but looking into the code I can't understand how that > is supposed to work, it doesn't look like a new line issue. The line endings have an impact on AnnotationPainter, on the line if (paintLength >= 0 && regionsTouchOrOverlap(paintStart, paintLength, clippingOffset, clippingLength)) { which, at the moment, always return false (paintLength < 0) and skips drawing for \r\n line endings. I believe the problem is not that code itself, but rather how the CodeMiningManager turns the LineEndCodeMining into an InlinedContentAnnotation for that case.
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/190801
I'm closing this one as the feature is available in I-Build and can already work with projects that already provide an ITextSelection->IVariable adapter. Further issues, improvements or integration of eg JDT, should now be tracked in separate bugs.
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/190801 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=d2b269147d32d23fd862634be8fff8bc65ea23a3
Recently I have also encountered some problem with the line ending code mining, see https://github.com/eclipse/xtext-eclipse/issues/1947
