Community
Participate
Working Groups
It would be useful to have some way of scoping the file search, perhaps by providing file paths that should be searched. As it is right now, the performance of search is fairly unusable if you are pointing your server at an entire eclipse workspace. Pointing it a single project (like org.eclipse.e4.webide) helps, but a common use case right now is that i want to look at the code in both the editor project and the webide project, and perform searches across only those two subfolders. So, for example, if I'm pointing the server at the location of my entire workspace, i'd like to be able to tell the search servlet to confine its searches to "/org.eclipse.e4.webeditor", "/org.eclipse.e4.webide" We are starting to build UI that lets the user scope the navigation tree so that they don't have to see everything at once, but we need a corresponding way on the server to confine the searches in such a way.
This is actually already working because we store a "Location" field in the search index. For example, this will only return files containing "foo" in the given project: http://localhost:8080/search/search.html#../filesearch?q=foo+Location:/file/d/* However the search results page is not aware of this and it fails to do the post-processing on the results (it needs to ignore the Location: part of the query).
This bug has been there for a long time. I was thinking about scoping the search result down (e.g. sorting after the full range search). As server already supports the scoped search, we should consider what the best UI(e.g. select folder/folders in the navigator first?) is for the user to have the scope before typing the search term. This is the first thing I would like to think about in 0.4.
There several interesting options we may consider or scoping: 1.Select folder/folders in the navigator and do search from the tool bar if multiple folders are selected. 2.Make a folder favorite and do search from there. 3.Make a work set which remembers all the folders I need. Then do search from there. All theses options need a prompt to input search term, as Susan mentioned at the last in the description of bug 361564. I think option 3 is most useful for me.
Susan, if we are considering scoping on multiple selection of folders, we want to approach "actions on a group of items". Do we already have a bug for this ?
(In reply to comment #4) > Susan, if we are considering scoping on multiple selection of folders, we want > to approach "actions on a group of items". Do we already have a bug for this ? this should work using the selection service. For example you can select multiple files in the navigator and then delete them. The navigator explorer code ties check boxes to the selection service. What we are missing right now is generic support for select all/deselect all but the rest should work.
(In reply to comment #5) > (In reply to comment #4) > > Susan, if we are considering scoping on multiple selection of folders, we want > > to approach "actions on a group of items". Do we already have a bug for this ? > > this should work using the selection service. > For example you can select multiple files in the navigator and then delete > them. The navigator explorer code ties check boxes to the selection service. > What we are missing right now is generic support for select all/deselect all > but the rest should work. Maybe we need more actions on a selection set. The reason I asked this is because user may want to select several folders he is working on, then search on these folders. Further more, if we can make the selection a favorite or working set, I can always start search from there. In self hosting as a real example I only care ../client/core and ../client/git. Of course, we should also consider the UI after user takes search action on a selection. The simple way to do so is to bring the user to the search page with the title showing that scope. This will be the same behavior if he clicked on the search button in the banner without input any thing.
Maybe a simpler option is to scope the search to the current "root" of the navigator. This is how search works in e.g., windows 7 file explorer. This way you don't need a special "Search" command in the menu. This is admittedly not as powerful as "search in these four folders" but makes for a simpler UI.
(In reply to comment #7) > Maybe a simpler option is to scope the search to the current "root" of the > navigator. This is how search works in e.g., windows 7 file explorer. This way > you don't need a special "Search" command in the menu. This is admittedly not > as powerful as "search in these four folders" but makes for a simpler UI. Good idea. I will take it as a starting point for scoped search.
(In reply to comment #6) > Maybe we need more actions on a selection set. > The reason I asked this is because user may want to select several folders he > is working on, then search on these folders. Further more, if we can make the > selection a favorite or working set, I can always start search from there. > In self hosting as a real example I only care ../client/core and ../client/git. I don't think we should invent a "working set" concept to support this. I think we'd be best to infer the scope based on where the user is, or once the user is on the results page and saving a search, they could further say "ignore these folders" etc. (In reply to comment #7) > Maybe a simpler option is to scope the search to the current "root" of the > navigator. This is how search works in e.g., windows 7 file explorer. This way > you don't need a special "Search" command in the menu. This is admittedly not > as powerful as "search in these four folders" but makes for a simpler UI. +1...navigator is probably a special case. We may be able to infer scope based on other pages (git, etc) but we need to clearly show what scope we used in the search results and provide a way for the user to change that scope. From a performance point of view, it's better to infer a smaller scope and offer broadening, then to search all and then later say...do you want to limit scope.
(In reply to comment #9) > I don't think we should invent a "working set" concept to support this. I > think we'd be best to infer the scope based on where the user is, or once the > user is on the results page and saving a search, they could further say "ignore > these folders" etc. OK. I like the term "where the user is", which will always be the "Location" field we pass to the search engine. Later on if the user wants to refine the result again they can use the filtering actions in the result page, e.g., actions based on selection. > +1...navigator is probably a special case. We may be able to infer scope based > on other pages (git, etc) but we need to clearly show what scope we used in the > search results and provide a way for the user to change that scope. Several points I would like to address further: 1.Search result will always be a separate page, with bread crumb showing the scope. 2.Navigating on the bread crumb from search result page will invoke search on the new scope. > > From a performance point of view, it's better to infer a smaller scope and > offer broadening, then to search all and then later say...do you want to limit > scope. I am not completely clear here. We are going to do pagination that will improve the performance. Do you mean something else? Could you word a simple work flow?
(In reply to comment #9) > From a performance point of view, it's better to infer a smaller scope and > offer broadening, then to search all and then later say...do you want to limit > scope. With Lucene I don't think performance will be an issue. It is extremely scalable. However scoping the search is more likely to return what the user is looking for I think. Getting 10,000 matches is never very helpful.
(In reply to comment #11) > (In reply to comment #9) > > From a performance point of view, it's better to infer a smaller scope and > > offer broadening, then to search all and then later say...do you want to limit > > scope. > > With Lucene I don't think performance will be an issue. It is extremely > scalable. However scoping the search is more likely to return what the user is > looking for I think. Getting 10,000 matches is never very helpful. I think the first level scope should be "where user is". As long as we can understand "current root"(e.g. navigator, git ?), we always scope down to that. Then in the result page you have chance to broaden or scope down again: 1.Clicking on bread crumb will broaden. 2.Checking/un-checking on foldes or file level will scope down again. The only issue is the combination of check box and pagination. For example if you have 100 matched files and the page size is 30: In the first page you scoped the file matches to 10. But if you go to page 2 and come back again, the file number will be 30 again.
(In reply to comment #12) > The only issue is the combination of check box and pagination. > For example if you have 100 matched files and the page size is 30: > In the first page you scoped the file matches to 10. > But if you go to page 2 and come back again, the file number will be 30 again. Are you thinking that checking (or unchecking) results acts as a "remove from view?" Is everything checked initially or does check mean "hide". Will have to see how this feels. As for the number of matches changing when you go forward back, that sounds like UI state we should be saving. If we remember the checkbox state on the page, and if the user had scoped from 30 to 10 on page 1, went to page 2, and came back, we'd still show just 10. Another point is that the user would need to tell by looking at the page that some results were filtered out. They can see the results item that was ignored/removed, or maybe some kind of indication (like "Showing 10 results of 30") that would allow them to get results back. I kind of like the idea of remembering the state (the way we do nav expansions or checkboxes) because then you can kind of have working set behavior without ever explicitly going and defining one, it just remembers what you had unchecked/checked before. but I could also imagine wanting to "compress" the results in that case, so that if, say, my filters caused only 10 of 30 to show, I may want the paginated results to show the other hits that I decided to keep. Not sure how to achieve this, we can iterate once we try the whole idea of the checking.
(In reply to comment #13) > Are you thinking that checking (or unchecking) results acts as a "remove from > view?" Is everything checked initially or does check mean "hide". Will have > to see how this feels. There will be a tool bar action "hide all checked". But check box will not be available on detail matches, which means you have a to hide in file and folder levels. There will also be a check/un-check all for convenience, similar to git status page. > As for the number of matches changing when you go forward back, that sounds > like UI state we should be saving. If we remember the checkbox state on the > page, and if the user had scoped from 30 to 10 on page 1, went to page 2, and > came back, we'd still show just 10. We can do this. Ideally we should bring another 20 to the first page but it needs chain request to server because server always give back unfiltered result. > Another point is that the user would need > to tell by looking at the page that some results were filtered out. They can > see the results item that was ignored/removed, or maybe some kind of > indication (like "Showing 10 results of 30") that would allow them to get > results back. I would like to refresh the browser to bring them back. Showing filtered out items is noisy to me as an end user. > I kind of like the idea of remembering the state (the way we do nav expansions > or checkboxes) because then you can kind of have working set behavior without > ever explicitly going and defining one, it just remembers what you had > unchecked/checked before. but I could also imagine wanting to "compress" the > results in that case, so that if, say, my filters caused only 10 of 30 to show, > I may want the paginated results to show the other hits that I decided to keep. > Not sure how to achieve this, we can iterate once we try the whole idea of the > checking. It really depends on user's experience. I may want to filter first page, replace all ONLY on first page, then go to next page and repeat. But I may optionally want to go through all the pages and see my scoped results in one page and work on it. Despite how UI will look like, there should be an action, like, I want to compress my result in one page and do further action. In this case, internally, all results are in cache and we do not want to bother server any more.
(In reply to comment #14) > It really depends on user's experience. > I may want to filter first page, replace all ONLY on first page, then go to > next page and repeat. > But I may optionally want to go through all the pages and see my scoped results > in one page and work on it. I agree that any "compression" would have to be explicit. > > > Another point is that the user would need > > to tell by looking at the page that some results were filtered out. They can > > see the results item that was ignored/removed, or maybe some kind of > > indication (like "Showing 10 results of 30") that would allow them to get > > results back. > I would like to refresh the browser to bring them back. Showing filtered out > items is noisy to me as an end user. I think the caching and reload behavior is where we were assuming different things. You are wanting reload to mean "start over, forget my filtering." I was thinking that you were trying to set up more permanent searches so that reload would search again, but would keep previous filtering. In which case we must show what filtering is applied so that a user could say, "Give me all results." The statefulness of what I'm describing is weird, though, so maybe instead, we should just focus on providing a way to "save search" that actually remembers all the state so that if I have a set of results and filtering that I frequently use, I can always get back to that. One of your early requirements statements talked about always wanting to search in a couple of bundles. We were trying to avoid a new "working set" concept but I think the requirement is valid.
(In reply to comment #15) > I think the caching and reload behavior is where we were assuming different > things. You are wanting reload to mean "start over, forget my filtering." I > was thinking that you were trying to set up more permanent searches so that > reload would search again, but would keep previous filtering. In which case we > must show what filtering is applied so that a user could say, "Give me all > results." Now I agree. > The statefulness of what I'm describing is weird, though, so maybe instead, we > should just focus on providing a way to "save search" that actually remembers > all the state so that if I have a set of results and filtering that I > frequently use, I can always get back to that. Good point. Lets call it a search config. Currently the "save search" just simply save the hash from URL. In case of search on current root, the location will be in the URL as well so we get that free. We need to think about saving filter info. > One of your early requirements statements talked about always wanting to search > in a couple of bundles. We were trying to avoid a new "working set" concept > but I think the requirement is valid. When I requested "working set", I was thinking about not only search but possibly other actions as well. "working set" is just a convenient entry for search. If we will have "save search with filter info", it almost equals to "start search from a working set". The only difference is that with working set you can also change the search string.
Pushed a simple solution with 9b1ac746d1c662060b872e2c0d2d419dde55036f. If you search from navigator, it searches from the current root now. Looking at git log now...
pushed another fix with ca3bb698afb98d732de056d324c44d6bbb671424. You can go scope search from both navigator and git log page, from the current root. Also added bread crumb in the search result page. You can scope up the search on the bread crumb with the same search string.
The scope search is done. If there is any other enhancement please open a new one.
