Community
Participate
Working Groups
Build ID: M20090211-1700 Steps To Reproduce: I'm not quite sure the best way to gracefully fit this into Eclipse, but this is a problem I run into frequently: 1. While working on my Mac, I see a string in the Eclipse UI or in the UI of our Eclipse-based product. I want to find that string in the source, so that I can examine the code near it. 2. I type the string into Eclipse's search box (in the "File Search" dialog), and tell it to search all *.properties files. Often -- in fact, most of the time -- Eclipse doesn't find the string I was looking for, because the original string in the .properties file includes an ampersand somewhere in it, to indicate which letter should be the keyboard accelerator on Windows and Linux. The Mac OS doesn't use those keyboard accelerators and doesn't display them, so I have no way of knowing where the ampersand goes. I have come up with two workaounds, both of which are very tedious: Either rerun the app on Windows to see where the ampersand goes, or type a ridiculous regular expression with an optional ampersand in each position -- instead of "File", I could type "&?F&?i&?l&?e". Ugh. What I would really like is a checkbox in the File Search dialog: [ ] Ignore ampersands This would have the effect of stripping ampersands from each line BEFORE comparing it to the string I'm searching for. This should be done in such a way that it still allows me to search for regular expressions; for example, if the original string is "Fi&le", and I search for "Fi.e", it should match (because first the ampersands were stripped, leaving "File", and then it was compared to my regular expression "Fi.e"). (And by the way, "&&" should map to "&") Stripping ampersands is easy -- the hard part of this feature, as I see it, is doing it in a way that is consistent with Eclipse's philosophy of everything being modular and extensible. It doesn't necessarily make sense to hard-code an "Ignore ampersands" option to the File Search dialog, because this whole thing of stripping ampersands is really very specific to the case of strings that will be going into the UI of a Windows or Linux program. And yet implementing the feature in any other way not only requires a lot more work, but also introduces UI headaches: If more than one plugin contributes enhancements to the File Search dialog, how do you display them all? More information:
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.
