Community
Participate
Working Groups
The Generic Editor shows error markers, but doesn't provide the quickfixes to troubleshoot the errors. To try it: * Create a file such as a MANIFEST.MF with errors and quick-fixes available for those errors * Open With > Generic Editor * See error markers there, no quickfix proposal
This is the same behavior on the plain text editor. Would it make sense and be an acceptable change to try to enable quick fixes on the default text editor as well if the generic editor can inherit from it?
(In reply to Mickael Istria from comment #1) > This is the same behavior on the plain text editor. Would it make sense and > be an acceptable change to try to enable quick fixes on the default text > editor as well if the generic editor can inherit from it? From the user perspective it doesn't matter in which editor marker appears, but *if* it appears and can be fixed in one editor, why it should not be fixable in another?
That would most likely require to add a dependency on org.eclipse.ui.ide, which defines the marker resolution extension point. I'm not sure this is something we want to allow for the legacy text editor. However, for the Generic Editor, I don't see anything wrong with adding this dependency. @Dani: WDYT? Can the generic editor depend on the org.eclipse.ui.ide bundle to provide that feature?
(In reply to Mickael Istria from comment #3) > That would most likely require to add a dependency on org.eclipse.ui.ide, > which defines the marker resolution extension point. I'm not sure this is > something we want to allow for the legacy text editor. However, for the > Generic Editor, I don't see anything wrong with adding this dependency. > @Dani: WDYT? Can the generic editor depend on the org.eclipse.ui.ide bundle > to provide that feature? Yep, our Text Editor in 'org.eclipse.ui.editors' does the same.
New Gerrit change created: https://git.eclipse.org/r/90382
Gerrit change https://git.eclipse.org/r/90382 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=92a0d5c389d95693544840b4f1c25f670ea4b0f7
New Gerrit change created: https://git.eclipse.org/r/91599
Gerrit change https://git.eclipse.org/r/91599 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=5985a1edc5adad4a81892f9229e3269c8b25e794
Please remove the dependency from org.eclipse.ui.genericeditor.tests to org.eclipse.ui.tests.harness. The eclipse.platform.text repo should not require developers to check out the huge eclipse.platform.ui repo, and especially not the ill-designed test bundles in that repo that clutter runtime workspaces with bad contributions.
org.eclipse.ui.tests.harness.util.DisplayHelper#runEventLoop(Display, long) is responsible for the DNFs on Windows since I20170222-2000: [java] org.eclipse.test.EclipseTestRunner$ThreadDump: for thread "main" [java] at org.eclipse.swt.internal.win32.OS.WaitMessage(Native Method) [java] at org.eclipse.swt.widgets.Display.sleep(Display.java:4859) [java] at org.eclipse.ui.tests.harness.util.DisplayHelper.runEventLoop(DisplayHelper.java:147) [java] at org.eclipse.ui.genericeditor.tests.HoverTest.getHoverShell(HoverTest.java:126) [java] at org.eclipse.ui.genericeditor.tests.HoverTest.testHover(HoverTest.java:86) Looks like that method calls Display#sleep() without ensuring that another thread eventually wakes up the main thread.
(In reply to Markus Keller from comment #10) > org.eclipse.ui.tests.harness.util.DisplayHelper#runEventLoop(Display, long) > is responsible for the DNFs on Windows since I20170222-2000: Thanks for checking Markus. Before I implement a waitAndDispatch manually, do you have any idea of another existing method (accessible from platform.text) which could do the same thing in a better way?
I don't know what exactly is wrong with DisplayHelper#runEventLoop(..), but in org.eclipse.jdt.text.tests, we've removed all usages of it because it caused trouble. In your case, the problem could also be the endless loop you implemented in HoverTest#getHoverShell(..) in case the condition never becomes true. A better way to implement this is to use waitForCondition(..). I've cleaned up a few things, removed the dependency on platform.ui tests, and added a copy of DisplayHelper to org.eclipse.jface.text.tests.util: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=dad356880b62128e58665dd3e641e51ab61e03c0
Tests are looking good for I20170308-2000, just two failures due to bug 513394 (firewall dialog): java.lang.AssertionError at org.eclipse.ui.genericeditor.tests.HoverTest.getHoverShell(HoverTest.java:142) at org.eclipse.ui.genericeditor.tests.HoverTest.testHover(HoverTest.java:94) at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:749) at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:350) ... and similar for HoverTest.testProblemHover.
Thanks a lot for looking at it Markus, it's much appreciated! I've opened bug 513399 to consider improving the state of the DisplayHelpers in general some day.
(In reply to Markus Keller from comment #12) > I've cleaned up a few things, removed the dependency on platform.ui tests, > and added a copy of DisplayHelper to org.eclipse.jface.text.tests.util: > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/ > ?id=dad356880b62128e58665dd3e641e51ab61e03c0 Incorrect reference, looks like http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=dad356880b62128e58665dd3e641e51ab61e03c0 is the correct one. In master, I still see a dependency to org.eclipse.ui.tests.harness. Opened Bug 516534 for that.
This is marked as "fixed" but I'm still having trouble with the GenericEditor, is there anything special to consider compared to other editor types? In the "Problems View" my Quickfix is available and can be applied, but in the Generic editor neither STRG+1 nor clicking on the marker icon works (nothing happens, my code is never called).
Here I see (with Wild Web Developer in a .css file; inserting a "background-colo: blue") a quick-fix accessible by Ctrl+1 or hovering on the error; but on the icon marker only error is shown, no quickfix.
Really strange. I noticed that when i open it in the plain text editor I can CTRL+1 and then get "no suggestions available", CTRL+1 in generic editor for the same file simply do nothing.
The problem is in org.eclipse.ui.internal.genericeditor.markers.MarkerResoltionQuickAssistProcessor.computeQuickAssistProposals(IQuickAssistInvocationContext): if (invocationContext.getOffset() >= position.getOffset() && invocationContext.getOffset() + Math.max(0, invocationContext.getLength()) <= position.getOffset() + position.getLength() && annotation instanceof MarkerAnnotation) { for my particular example > invocationContext.getOffset() = 609 > position.getOffset() = 598 > invocationContext.getLength() = -1 > position.getLength() = 0 this evaluates to > if (609 >= 589 && --> true > 609 + Math.max(0, -1) <= 589 + 0 && --> false > annotation instanceof MarkerAnnotation) { --> true > --> false and because of this my QuickAssist processor is never called. What indeed works is placing the cursor at the beginning of the line. Clicking at the item seems to never work.
@Christoph Please submit a new bug report for this with the details mentioned in last comment.
