Community
Participate
Working Groups
20011114 - Open an editor on a class - Select a word - Open the Find/Replace dialog (^F) - The selected word is used in the dialog (this is good) - Now click on a method in the Outline view - Click back on the editor to give it focus again The text in the Find/Replace dialog changes to the method name? This is bad. Another example: - Select some random text in your editor - Now open a second editor - Open the Find/Replace dialog, if it wasn't already open - Type something into the dialog to search for in the second editor - Give focus back to the original editor The text in the Find/Replace dialog changes to whatever was selected in the first editor? Why? Perhaps there are some people who actually use this "giving focus to editor changes text in Find/Replace dialog" feature, but I suspect there are more people annoyed by it than there are people who find it useful. I would prefer that if someone wants to re-populate the dialog text from selected text, they simply type ^F again. They don't have to bring up the dialog again, just type ^F to re-populate. This works, and it is intuitive and useful. The "automatic re-populating on focus gained" behavior is something I have found annoying for a very long time now. I am constantly changing editors, and every time, I have to drop down the combo box to get my search text back.
"Unassign" PRs because of changes in staffing
The dialog works on the active find/replace target. Each time a target gets active it configures the dialog. There are no plans to change this.
This stupid thing burned me yet again. I had a bunch of .html files that I had found using 'Search'. I had a Find/Replace dialog open to change: ' < ' to ' < ' The find string changed sometimes, based on the selection. In one case, it changed ' < ' to '<' which I did not notice. This meant that the rest of my searches subtly failed to find the string ' < ' and I believed I was done (only to find out later that I was half done and unable to find quickly where the problem began). Since the files are .html, I don't even get a compiler warning that something is bad. Why exactly is my original search string being modified?
>Why exactly is my original search string being modified? Because we retarget the dialog to the active editor since the initially targeted use case was to find/replace a string in the active editor. There's global search/replace which is intended to be used for text operations spawning more than one file. However, I agree that your scenario should be supported as well. Maybe we can add an option to the dialog (not a preference) like "Sticky" which keeps the dialog's find/replace strings.
Can you describe a concrete scenario where modifying the string when the editor is changed is actually useful? Personally, if I want the string to change to a newly-selected search string, I simply type ctrl+F again to repopulate the dialog. I have NEVER - honestly, NEVER - been happy with this misled dialog trying to "help me" by throwing bogus search strings into the Find field. It is always the wrong thing, sometimes ludicrously so. I can recall times when I did a Find, and then selected a large area of text in one editor, copied, switched to another editor, pasted the stuff, then went back to the first editor to Find another instance of the original thing, and *POOF*, there is this huge chunk of text in the Find field - and not only that, but the scope changes, and the darned dialog thinks that I suddenly want it to only search in the selected lines instead of the whole file... (the silly dialog doesn't realize that it is now looking for X in the scope of X, and it's only ever gonna find one instance....) Further, if I happened to have "Whole Word" selected, then of course all 4 pushbuttons in the dialog become disabled, and there have been times that I didn't at first notice that the Find field was repopulated, and all I knew was that the dialog would no longer do the one thing that I had asked it to do, and I found myself fighting with the darned thing to get back to the place I originally intended. Inside my head I am shouting at the dialog, "Stop Helping Me!!!!! I am still smarter than you!!!!! And on that day that you become smarter than me, I will *ask* you for help - unsolicited help is *not* appreciated!!!" So, please, re-evaluate the use cases before just throwing a "sticky" checkbox into it. If it really is true that most other people work in some completely different way than I do, then I will concede that a "sticky" box would help me greatly... as long as the "sticky" box was itself 'sticky', and once I selected it, the dialog would NEVER decide that I wanted it unselected <g>.
Sorry CAR, you are never smarter than Eclipse.
*** Bug 44789 has been marked as a duplicate of this bug. ***
I wish someone would fix this thing. As CAR said, "Can you describe a concrete scenario where modifying the string when the editor is changed is actually useful?". If no such scenario exists, why does it work this way?
Please consider bug bug #64584 for more details (which has been marked as a duplicate of bug #64040, incorrectly in my opinion)
+1 for never changing anything in the find dialog as long as it's open (or at least a 'sticky' option which can stick to 'checked' all the time ...)
*** Bug 71110 has been marked as a duplicate of this bug. ***
Interesting that nobody can describe a scenerio where the current behavior makes sense.
Saw this again. Please assign it. (It was opened more than 3 years ago, and the problem has existed for even longer than that... <grin>). Please see: https://bugs.eclipse.org/bugs/show_bug.cgi?id=44789#c5 and: https://bugs.eclipse.org/bugs/show_bug.cgi?id=64584#c2 as well, for more info. Please do *not* add a sticky option or a preference or anything like that, because I think that once the Find/Replace dialog is open, it should *never* be repopulated for *any* reason other than the user typed or clicked something with the clear intention of changing something in the Find/Replace dialog. For example, typing ^F with something else selected in the editor, or clicking on or typing into any of the controls in the Find/Replace dialog itself. Switching editors does NOT imply a desire to repopulate the Find/Replace dialog or change its scope, selection, or goals in any way. In fact, it is completely unexpected, and I would call this a pretty clear usability bug. Please note that removing a confusing feature is just as good for a product as adding a new feature. Thanks!
Kai, this is the bug I was telling you about the last time I saw you. Since it has not been assigned, I'm assuming no one but the CC: list ever sees email about it. It's really, really annoying and since no one is able to explain why the current behavior could ever be useful, also frustrating. Now that we have refactoring, it matters less. I use refactoring to change things more than Find/Replace.
Yes, refactoring helps, and also the global "Replace..." on Search helps. But I still trip over this, and today it was while editing a similar comment across multiple files where each file needed a slightly different replacement string. Some of my open editors happened to have a selection from a previous visit to that editor, and when I went to those, blam, I had to manually reconfigure the Find/Replace dialog back to what I wanted. This dialog is the one that I talk to the most <g>. As in, "Hey - cut that out!" ;)
Correcting severity. Since nobody can even come up with a contrived story to explain why the current behavior should be useful, this is really a defect.
Fixed in the Christmas build I20041221.
Merry Christmas Kai!
Yeah! Merry Christmas, Kai! And Thanks!
