Community
Participate
Working Groups
Follow-up on http://twocentsonsoftware.blogspot.de/2018/02/eclipse-vs-intellij-empirical-rant.html in which a user describes his frustration with the Eclipse IDE. I agree that we have have manually add * is bad UX. In the past we changed that for exmaple in the PDE editors to automatically add * if the user does not define a wildcard. I suggest to adjust Open Type accordingly.
Mickael, what do you think?
I support this idea, but I think it's important to be careful about the results being well ordered. For example, if I type "MyTy", I want "MyType" to show as first result, before "AbstractMyType". It's important to have some tests capturing the user expectations first because experience on Open Type dialog has shown that small changes can lead to perception of a regression.
(In reply to Mickael Istria from comment #2) > I support this idea, but I think it's important to be careful about the > results being well ordered. For example, if I type "MyTy", I want "MyType" > to show as first result, before "AbstractMyType". It's important to have > some tests capturing the user expectations first because experience on Open > Type dialog has shown that small changes can lead to perception of a > regression. +1
Jonas, can you try to implement this? To add wildcards you can get inspiration from https://git.eclipse.org/r/#/c/118488/ But we needs also to present the prefix matches before normal matches. IIRC Leo already added some logic for sorting in the past but this memory might be wrong.
(In reply to Lars Vogel from comment #4) > Jonas, can you try to implement this? To add wildcards you can get > inspiration from https://git.eclipse.org/r/#/c/118488/ > > But we needs also to present the prefix matches before normal matches. IIRC > Leo already added some logic for sorting in the past but this memory might > be wrong. Interesting. I don't recall adding anything like that to platform ui. I'm a SWT-Cave dweller who rarely comes out to the "platform.ui" land on the surface. Maybe it was my evil twin?
I think Lars was more thinking about Lucas.
(In reply to Leo Ufimtsev from comment #5) > (In reply to Lars Vogel from comment #4) > > Jonas, can you try to implement this? To add wildcards you can get > > inspiration from https://git.eclipse.org/r/#/c/118488/ > > > > But we needs also to present the prefix matches before normal matches. IIRC > > Leo already added some logic for sorting in the past but this memory might > > be wrong. > > Maybe it was my evil twin? Evil twin here, @Jonas the work to ensure that the prefix matches come first should go in FilteredItemsSelectionDialog, look https://git.eclipse.org/r/#/c/111162 for an example of how perfect matches were shown first
(In reply to Lucas Bullen from comment #7) > Evil twin here, Sorry Leo und Lucas for the mixup.
(In reply to Lars Vogel from comment #8) > (In reply to Lucas Bullen from comment #7) > > Evil twin here, > > Sorry Leo und Lucas for the mixup. I was just making fun. Me & Lucas work in the same office.
(In reply to Leo Ufimtsev from comment #9) > I was just making fun. Me & Lucas work in the same office. :-)
New Gerrit change created: https://git.eclipse.org/r/120165
+1 need possibility in settings to use * automatically prefix a search string with * I always must add *, and this is bad UX I know this feature must be by default, like in other IDE's also in Open Type Dialog too
+1 While working with VS Code or IntelliJ IDEA more now, I realized how far behind Eclipse is regarding searching for files (Ctrl+Shift+R, Ctrl+E), or even for types (Ctrl+Shift+T) in a really user-friendly way. So I think it would be great if someone could revive this issue again, although it kind of surprises me it is not upvoted more. This feature is also questioned on SO: https://stackoverflow.com/questions/27879252/eclipse-fuzzy-search-in-quick-switch-editor, but with no big traffic as well. Anyway, **regarding expected functionality**, one can inspire for example from the aforementioned apps. Note that today, it is not just about the possibility to avoid using '*', and the searchers are really smart in "splitting" the typed search expression onto file paths within a workspace. **Regarding how to implement this**, I'm not an expert in this, but it looks like there is, at minimum, this Eclipse plug-in: [Eclipse-GotoFile-Plugin-kai](https://github.com/adelarsq/eclipse-gotofile-plugin-kai). I haven't checked it out yet, it is 10 years old and it builds on another one which is even older. Yet it seems like supporting various kinds of fuzzy searches which can be seen in today's modern editors.
Patches are more than welcome. There is already a link to a patch that can serve as a basis for further contributions.
OK, so I have done some research in this area. Just a few high-level notes for the beginning (I'm preparing a more in-depth mind map which I might share later if I have still time & energy for this.): 1. The existing patch was inspired from https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/118488/, linked to bug 531746 (the same as this one, but for the "search dropdown" - Ctrl+E). 2. Both patches are simple, yet they brake the other searching functionality (like for example CamelCase matching), that's why they got rejected. 3. For actually implementing this feature request, it looks like we need to look more deeply into the UI objects hierarchy. 4. Namely the `SearchPattern` class, which is a common denominator of all the searches, probably has to be extended - because currently, based on the search string, it supports either just RULE_PATTERN_MATCH (when seeing a wildcard), or RULE_CAMELCASE_MATCH, not both.
Ad 4. `SearchPattern` - There is a gotcha: JDT's `FilteredTypesSelectionDialog` uses JDT's own "clones" of `SearchPattern`, `StringMatcher` etc. for some reason. The `StringMatcher` even seems to be a 100% duplicate of the core class at the first sight. So changing also the Open Type dialog in this way and keeping this in sync might be challenging...
(In reply to Petr Bodnar from comment #16) > Ad 4. `SearchPattern` - There is a gotcha: JDT's > `FilteredTypesSelectionDialog` uses JDT's own "clones" of `SearchPattern`, > `StringMatcher` etc. for some reason. The `StringMatcher` even seems to be a > 100% duplicate of the core class at the first sight. So changing also the > Open Type dialog in this way and keeping this in sync might be challenging... If you think it's doable without any functionality loss, please consider submitting a patch to JDT to have it using core functionality. Such factorization always end up being highly profitable to both sides.
(In reply to Mickael Istria from comment #17) OK, I have just found bug 562393 which is opened to resolve the duplicated `StringMatcher` in JDT. I guess touching this class won't be necessary to resolve this issue. Anyway, I would probably focus on the Open Resource dialog for now and we will see what emerges from that...
FYI, I prepared somewhat related SearchPattern tests cleanup at https://git.eclipse.org/r/192602. I hope there is no need to open a separate issue for that in this case.
Hi there, thank you Mickael for merging the previous tests cleanup commit. I'm trying to commit a working prototype of the actual implementation, but I get what is described in bug 541049, although I think I follow exactly the same procedure as previously. BTW I also cannot comment on the closed Gerrit change, getting "Error 500". So I have no idea what could go wrong. Should I file a new bug for that?
Oh, OK, it looks like you are just migrating to GitHub (https://github.com/eclipse-platform/eclipse.platform.ui/)? Where can I find information on that? I cannot see anything on https://wiki.eclipse.org/Platform/How_to_Contribute...
(In reply to Petr Bodnar from comment #21) > Oh, OK, it looks like you are just migrating to GitHub > (https://github.com/eclipse-platform/eclipse.platform.ui/)? Where can I find > information on that? Indeed, Platform is now at GitHub. Documentation about setting up environment, writing code and so on is still accurate (only the Git repo URL may differ). Documentation about submitting a contribution via GitHub is available on Github documentation site.
Well, not quite exactly what I was looking for, but thanks at least for this basic confirmation. So goodbye Gerrit and here comes the PR: https://github.com/eclipse-platform/eclipse.platform.ui/pull/12. Still WIP, review and further recommendations are pretty much welcome.
Discussion moved to https://github.com/eclipse-platform/eclipse.platform.ui/pull/12
