Community
Participate
Working Groups
In large projects, my directory and file trees are becoming very large. It would be nice to have a feature like Mozilla's search feature where you type in the web site and the browser finds the next string. Similar, it would be nice if eclipse would provide such a functionality for the navigator. Just click in the tree, and start to type - the navigator should find the next ocurrence of the string entered (matching also substrings, and not from the beginning as it works now). See the attached fake image.
Created attachment 12940 [details] Fake-example of my feature request
In Firefox or Mozilla, how do you advance to the next match? Do you have to wait for it to time out and type the substring again, or is there a key to advance? For navigating around large projects, I recommend using Ctrl+Shift+T (Open Type) and Ctrl+Shift+R (Open Resource), optionally with Link with Editor on in the Navigator and/or Package Explorer. These prompters have type-ahead filtering (prefix matching by default). If you want to match a substring use, e.g. *substring*.
Mozilla and Firebird are advanding to the next match by hitting F3. I did not knew about "Open Resource" so far - it looks very promising. Could it made possible that it matches substrings by default (or by configuration?)
Came across this bug while searching for another. I've recently come to the same conclusion that we should make this support pervasive since the lists/trees are getting huge. It'd be cool if you got it for free for any list/tree viewer, but at the least it should be easy to plug.
Assigning to Kevin: I wouldn't this in the 3.x stream, but it feels like this notion (i.e. that trees and lists must always be prepared to show a subset of their contents) needs to be part of our model for the workbench in 4.0.
Agree, good 4.0 item. I'm marking it as such so we can track it.
The interesting question for this feature is: Can it find elements inside nodes that are not yet expanded. I assume you want it to do this. Problem is that this is an expensive operation. For example in the package explorer this would mean to open lots of Java files and JARs. Finding an element by name in a large model is something you better do with an index. We have 'Open Resource' and 'Open Type' which contain a lot of infrastructure to provide a good user experience (search in the background, history for immediate results) Use 'Navigate > Goto Resource', 'Navigate > Goto Type' to reveal an element in the package explorer/navigator
(In reply to comment #7) > The interesting question for this feature is: Can it find elements inside nodes > that are not yet expanded. Would it help if the search only accounted for previously expanded (i.e. cached) items? This would avoid the additional cost of a "deep" lookup and meet most user's expectations. Also, I would not expect it to search *inside* JARs, I only want a quick way to get to the artefacts in my project. > Finding an element by name in a large model is something you better do with an > index. We have 'Open Resource' and 'Open Type' Agreed, but as users get used,-) to quicksearch in dialogs, they'll expect this functionality in other areas too, where it makes sense. Curious about 4.0... is there anything on the wiki yet?
(In reply to comment #8) > Would it help if the search only accounted for previously expanded (i.e. > cached) items? This would avoid the additional cost of a "deep" lookup and meet > most user's expectations. Also, I would not expect it to search *inside* JARs, > I only want a quick way to get to the artefacts in my project. The key in my view is to automate the case where I know the thing is there in the tree, but visually scanning it is tiresome. So that matches your suggestion. On the other hand, it sure would be tedious if it failed because I hadn't expanded a /src folder yet. More so, it'd be confusing since a successful hit depends on whether I've seen the element already (since I started Eclipse today? ever in that workspace?), but my memory is only so good, so now I can't tell if a failure is because I've not yet seen it or it doesn't exist. So I think it needs to be driven off an indexer. But we may bound it to resources that exist in the workspace via a loaded project vs. resources which are referenced (e.g. within a JDK jar or an installed plugin). > Curious about 4.0... is there anything on the wiki yet? Not as yet.
Retitling bug (again). We tend to use "Filtered Tree" for these cases today, but I didn't mean to imply that a pervasive quick find would actually filter the list.
*** Bug 201319 has been marked as a duplicate of this bug. ***
This is a bit different than the original proposal (a search bar on each view), but I thought I should mention it here. There is talk of having a search bar in the trim of an e4-based workbench. One idea is that it could do this style of "find" for the active part. Another idea from Bogdan was that it could be a good home for "quick access" style finding (Ctrl+3). So that you could always type the name of any command/dialog/part you were looking for and quickly find it. In the first case you are looking for "something to work with." In the second case you are looking for "something I want to do/open".
*** Bug 224208 has been marked as a duplicate of this bug. ***
*** Bug 195579 has been marked as a duplicate of this bug. ***
*** Bug 312043 has been marked as a duplicate of this bug. ***
*** Bug 322788 has been marked as a duplicate of this bug. ***
The index-based search from comment 7 and comment 9 requires each view to provide the infrastructure to efficiently search in an index of their model elements. Hence, this functionality cannot be added pervasively -- only view-by-view. I agree with Kevin that a search that considers all "previously expanded items" (comment 8) would be unsatisfactory. But what about a search that only considers visible items? That would not solve all problems, but it would help in many cases, would be easy to explain, and can be implemented for all views using only information from the label provider (so it matches exactly what the user sees). Ctrl+F on GTK+ already does something like this -- the only thing it misses is wildcard matching (except for a free * at the end). (In reply to comment #0) > [..] Just click in the tree, and start to type [..] I wouldn't change the platform behavior when the user just starts typing. But we could support Ctrl+F to start with an empty search pattern and the * key to start with "*" (so the user can easily search for substrings).
*** Bug 321586 has been marked as a duplicate of this bug. ***
*** Bug 224493 has been marked as a duplicate of this bug. ***
