Bugzilla – Full Text Bug Listing
| Summary: | [find/replace] Find/Replace dialog is too eager | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Carolyn MacLeod <carolynmacleod4> |
| Component: | Text | Assignee: | Platform-Text-Inbox <platform-text-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | eclipse, hudsonr, kai-uwe_maetzel, markus.kell.r, snorthov |
| Version: | 2.1 | Keywords: | usability |
| Target Milestone: | 3.1 M5 | ||
| Hardware: | PC | ||
| OS: | Windows 2000 | ||
| Whiteboard: | |||
|
Description
Carolyn MacLeod
"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! |