Community
Participate
Working Groups
I20070918-0010 The filter field in the Preferences dialog should support multiple keywords. Today, it e.g. finds a page with filter "java editor templates snippet macros", because that's the sequence of keywords defined for that page. However, it should also find the page with filters "template java", "java snippet", etc.
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
Created attachment 147936 [details] Proposed patch This is an early draft patch to propose an enhancement for the current filtering for the preference page.
It seems to work fine if I don't use wildcards, but as you mentioned, it breaks down in many cases when whildcards are used: - If I have an asterisk in the middle: "editor java" - many matches; "e*r java" - no matches - If I have a '?': "editor java" - many matches; "edito? java" - no matches - if I have a leading space: "editor" - many matches; " editor" - no matches The StringMatcher#parseWildCards() parses the pattern into segments, something like: pattern => [leading *] | [segment1 *] | [segment2 *] | ... [segmentN] | [trailing *] I think that while this parsing is done, it needs to parse word separators adding a level on top of this structure: pattern => word1 [| word2] ... [| wordN] where each word is [leading *] | [segment1 *] | [segment2 *] | ... [segmentN] | [trailing *]
Created attachment 148630 [details] Proposed patch Thanks for the advice!
New Gerrit change created: https://git.eclipse.org/r/105884
Gerrit change https://git.eclipse.org/r/105884 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=b1fd6652db198148357011db5e1a295263197519
Awesome, thanks Dina and Lucas. Dina, we are very sorry that it took us sooooo long to integrate your patch. Thanks to Lucas for picking it up and pushing it to Gerrit. Lucas, can you add a N&N to M3?
Pretty sure this causes the new test failure we have on all platforms: http://download.eclipse.org/eclipse/downloads/drops4/I20171020-2000/testresults/html/org.eclipse.ui.tests_ep48I-unit-win32_win32.win32.x86_8.0.html Looks like it filters too much now. assertion failed: tree item count 0 does not match expected: 1 org.eclipse.core.runtime.AssertionFailedException: assertion failed: tree item count 0 does not match expected: 1 at org.eclipse.core.runtime.Assert.isTrue(Assert.java:110) at org.eclipse.ui.tests.filteredtree.FilteredTreeTests.assertNumberOfTopLevelItems(FilteredTreeTests.java:182) at org.eclipse.ui.tests.filteredtree.FilteredTreeTests.testAddAndRemovePattern(FilteredTreeTests.java:117) at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:726) at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:348) at org.eclipse.test.UITestApplication.lambda$0(UITestApplication.java:195) at org.eclipse.test.UITestApplication$$Lambda$304/31470062.run(Unknown Source) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:37) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:182) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4213) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3820) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1150) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1039) at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:153) at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:680) at org.eclipse.ui.internal.Workbench$$Lambda$19/27798799.run(Unknown Source) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:594) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:148) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:151) at org.eclipse.test.UITestApplication.runApplication(UITestApplication.java:139) at org.eclipse.test.UITestApplication.run(UITestApplication.java:61) at org.eclipse.test.UITestApplication.start(UITestApplication.java:210) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:388) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:243) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:653) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:590) at org.eclipse.equinox.launcher.Main.run(Main.java:1499) at org.eclipse.equinox.launcher.Main.main(Main.java:1472) at org.eclipse.core.launcher.Main.main(Main.java:34)
(In reply to Dani Megert from comment #8) > Pretty sure this causes the new test failure we have on all platforms: > http://download.eclipse.org/eclipse/downloads/drops4/I20171020-2000/testresults/html/org.eclipse.ui.tests_ep48I-unit-win32_win32.win32.x86_8.0.html Why did you not wait for Hudson on the change? It reports a test failure: https://hudson.eclipse.org/platform/job/eclipse.platform.ui-Gerrit/13719/
Lucas, can you have a look at the test failure?
New Gerrit change created: https://git.eclipse.org/r/110487
Gerrit change https://git.eclipse.org/r/110487 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=abc63aa2a32d22a270d08cb909e12ae295e2ee5f
Tests still fail sometimes, e.g. http://download.eclipse.org/eclipse/downloads/drops4/I20171101-2000/testresults/html/org.eclipse.ui.tests_ep48I-unit-cen64-gtk2_linux.gtk.x86_64_8.0.html and http://download.eclipse.org/eclipse/downloads/drops4/I20171101-2000/testresults/html/org.eclipse.ui.tests_ep48I-unit-mac64_macosx.cocoa.x86_64_8.0.html They don't fail constantly, so, the fix might have introduced some race condition (didn't check the code).
And also failed on GTK+ 3: http://download.eclipse.org/eclipse/downloads/drops4/I20171101-2000/testresults/html/org.eclipse.ui.tests_ep48I-unit-cen64-gtk3_linux.gtk.x86_64_8.0.html
Again in http://download.eclipse.org/eclipse/downloads/drops4/I20171106-2000/testresults/html/org.eclipse.ui.tests_ep48I-unit-cen64-gtk3_linux.gtk.x86_64_8.0.html Please either take a look or revert the changes.
(In reply to Dani Megert from comment #15) > Please either take a look or revert the changes. AFAICS Lucas and Alex worked today on this. https://git.eclipse.org/r/#/c/110987/4/tests/org.eclipse.ui.tests/Eclipse+UI+Tests/org/eclipse/ui/tests/dialogs/ResourceItemLabelTest.java
Looks as if the last patch fixed the failing tests. Seems as if it was an issue with not giving enough time for the Open Resource view to update it's cache. http://download.eclipse.org/eclipse/downloads/drops4/I20171107-2000/testResults.php
Re-closing this bug as the failing test has stopped failing
Is it expected to show all pages that match one of the keywords ? I think we should change it when there are multiple keywords to show only patches that match all of them.
(In reply to Alexander Kurtakov from comment #19) > Is it expected to show all pages that match one of the keywords ? I think we > should change it when there are multiple keywords to show only patches that > match all of them. I assume with "patches" you meant "pages" ;-). Any "yes", I agree with you.
(In reply to Dani Megert from comment #20) > (In reply to Alexander Kurtakov from comment #19) > > Is it expected to show all pages that match one of the keywords ? I think we > > should change it when there are multiple keywords to show only patches that > > match all of them. > > I assume with "patches" you meant "pages" ;-). Any "yes", I agree with you. I think this is now how it works after fixing bug 534277.
*** Bug 515457 has been marked as a duplicate of this bug. ***
