Bugzilla – Full Text Bug Listing
| Summary: | Use last used search page instead of recommended one | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Marko Tomljenovic <marko.tomljenovic> |
| Component: | Search | Assignee: | Platform-Search-Inbox <platform-search-inbox> |
| Status: | CLOSED DUPLICATE | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | daniel_megert |
| Version: | 3.6.2 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Marko Tomljenovic
>because there is a better search that has been internally implemented.
What kind of search and who provides it?
When our developers edit c files they need to search not only in code (c files) but also in other file types since we are doing much code generation. For that either the regular text search is used or we use our internal Apache Lucene based search. > For that either the regular text search is used or we use our internal Apache
> Lucene based search.
So, you contribute the Lucene search, right?
Not yet ;) I would like to have something different. When registering a new search type you can specify file "extensions" for which this search page shall be opened by default. For the C/C++ search this alwas has the effect that if a user presses Ctrl+H while editing a C file always the C/C++ search is opened. Then he often switches to a different search that fits better. And this he has to do for each search execution. What would be nice is that the search dialog can remember the last used search type and use that instead of the recommended one. To not loose the original behaviour (use recommended) there could be a preference switch so that every user can decide on its own which behaviour fits better his needs. You have two choices: 1. If a user really doesn't want the "C/C++ Search", then they can simply hide that page, in which case it will default back to the File search page (or whatever fits best next). 2. You can contribute your own search (e.g. the Lucene one) that overrides the C+/C++ search page for .c and .cpp files. There are no plans to fix this. *** This bug has been marked as a duplicate of bug 33710 *** And if I provide a patch for this requirement? Would you then accept this? (In reply to comment #6) > And if I provide a patch for this requirement? > Would you then accept this? Isn't 1. from comment 5 doing mostly what you asked for in comment 0? If not, I would accept a high quality patch which introduces a new preference where the user can choose to always use the previously chosen page. Fixing bug 33710 is not possible because each page decides by itself how to initialize itself. Ok. Bringin in the patch in proper quality is not a problem (not doing the first patch). But it will take some time. Greets > Fixing bug 33710 is not possible because each page decides by itself how to > initialize itself. Actually the people in bug 33710 and its duplicates only need to preserve the page, so it's fine if you work on a patch for said bug. *** This bug has been marked as a duplicate of bug 33710 *** |