Summary: | [nls tooling] Provide a Properties File search | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Mike Morearty <mike> |
Component: | Text | Assignee: | JDT-Text-Inbox <jdt-text-inbox> |
Status: | ASSIGNED --- | QA Contact: | |
Severity: | enhancement | ||
Priority: | P3 | CC: | contact, daniel_megert, deepakazad, markus.kell.r |
Version: | 3.4.2 | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: |
Description
Mike Morearty
2009-03-12 04:17:16 EDT
Moving to Platform/Search One way to solve this would be a separate Properties Search (page) which would also allow to e.g. only search for key and/or values. What do you think Mike? Yeah, having a Properties Search page is not a bad idea. That might be a good way to go. Mike: This has nothing to do with text search, but to find the code that implements a dialog or view, I often use the 'Plug-in Spy' command (Alt+Shift+F1). (In reply to comment #2) > One way to solve this would be a separate Properties Search (page) which would > also allow to e.g. only search for key and/or values. hmm.. we will probably need a separate Search page for Bug 328019 as well. (In reply to comment #5) > (In reply to comment #2) > > One way to solve this would be a separate Properties Search (page) which would > > also allow to e.g. only search for key and/or values. > hmm.. we will probably need a separate Search page for Bug 328019 as well. Bug 328019 is about find/replace. Another approach would be to open up text search and allow participants like Java search already does (see bug 23341). (In reply to comment #6) > Another approach would be to open up text search and allow participants like > Java search already does (see bug 23341). I wouldn't allow participants to silently influence results in files that are already processed in the base infrastructure. I don't want a File Search that thinks it is smarter than me and takes away the possibility to do an exact text search. If we go in that direction, then the File Search participants would have to be configurable (so they would not be "participants", but something like "transformers"). Then, the mechanism could also be used for other similar use cases, e.g.: - search for a text that wraps lines in a Javadoc or block comment - search for text embedded in HTML or XML files, stripping away all markup tags and replacing entities like "&" by their value But a separate Properties Search page is probably the least expensive solution. (In reply to comment #7) > If we go in that direction, then the File Search participants would have to be > configurable +1 How about adding a 'Smart Search' option in the current File search dialog, if this option is enabled then based on file type the appropriate participant/transformer could be turned on. > But a separate Properties Search page is probably the least expensive solution. Can we cycle through the search pages in search dialog using keyboard? Can we do it using Ctrl+H itself ? If yes, then I can agree to another search page. Point is I get frustrated when the dialog opens with the wrong - the one I do not want - page activated. With one more page this probability will only increase :) (In reply to comment #7) See bug 337200. |