Community
Participate
Working Groups
Build Identifier: 3.6.2 We have users that write c code but typically do not use the "C/C++ Search" because there is a better search that has been internally implemented. It really annoys the users that always the "C/C++ Search" is opened when Ctrl+H is pressed while editing a C/C++ file. My requirement looks like this: There should be a preference where it can be selected whether the last used search tab shall be used or the "recommended" one. Reproducible: Always Steps to Reproduce: See details
>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 ***
