Community
Participate
Working Groups
1. While in incremental find mode, highlight ALL instances within the file with a search highlight colour. (Current selection changing while you type to find the NEXT instance should work the same way it does now - the highlight is a display annotation only.) The incremental search result annotation, like other annotations, could be shown on the vertical bar and overview bar as feedback saying where the search string was found, and the status bar could show the number of places in the current file where it was found. 2. In incremental find mode, after typing a sequence of characters that were found at least once in the file, have a way to switch to "incremental replace" mode (eg. Ctrl+H), which would then replace ALL the incremental find results SIMULTANEOUSLY with the next sequence of characters typed. In "incremental replace" mode, hitting Esc would cancel the replace and restore the original search string, or hitting Enter would exit "incremental replace" mode (returning to normal editing mode) with the replaced text left in the buffer. These two enhancements would make it possible to perform a search/replace all operation from the keyboard without having to pop up dialog boxes and use their accelerator keys. Also, being able to see the effect of the replace as you type the replace string would make it feel much safer to do since you can check the results and optionally cancel/commit them.
To be looked at in 3.2 where we plan to improve find/replace. See also bug 48463.
OK well if there is going to be a more general rethink of Find/Replace in Eclipse, might I also suggest considering replacing the Find/Replace dialog box with a toolbar a la FireFox. I worked with the author of ModelWorks JPadPro to design a similar feature for his product. The result was really powerful because the editor never loses focus and isn't partially covered by a popup dialog.
I think bug 48463 or one of its dups already mentions those ideas as well.
I like the idea in comment 0 - the infrastructure to go into linked mode similar to "Rename local (Ctrl+2 R)" is already there. Something to consider for bug 48463.
Actually, thanks to comment 4 I realised how close we are to getting enhancement #2 in comment 0. By using the keyboard shortcuts for "Incremental Find" and then "Quick Assist - Rename in File" I was able to get *almost* the behaviour I described. The differences I noticed are: a) Pressing Escape doesn't rollback the change - Escape and Enter have the same effect. b) This only seems to work on Java identifiers, ie. not on just any search string, and not in any kind of text editor.
*** Bug 106027 has been marked as a duplicate of this bug. ***
*** Bug 109471 has been marked as a duplicate of this bug. ***
*** Bug 112936 has been marked as a duplicate of this bug. ***
*** Bug 27995 has been marked as a duplicate of this bug. ***
*** Bug 129565 has been marked as a duplicate of this bug. ***
Unfortunately we have to defer this.
*** Bug 195455 has been marked as a duplicate of this bug. ***
In bug 195455 Catagay started to work on this as part of his GSoC project. Initial work and comments were made there but the discussion now goes on here. Catagay, I looked at you mockup in bug 99294 (https://bugs.eclipse.org/bugs/attachment.cgi?id=73493) and it is good starting point. Here's my feedback: - I expect the Find section to be hidden until I press Ctrl+F (like in Firefox). Hence it needs a control to close it again. It also needs a way to invoke next/prev, replace and option configuration as the final work should render the current Find/Replace dialog obsolete. - when the Find section appears we have to ensure that the performance is OK: since it makes the editor's viewport smaller you need to relayout the text, vertical and overview (i.e. horizontal) ruler. - the mockup only shows the Find field. This is the least interesting part as I can currently find strings using Ctrl+J without the dialog and see the feedback inside the status line. The interesting part will be how to do the replace. That's where I use Ctrl+F and that's where users normally run into the problem that the dialog hides the text. So far I did not yet look at the code. Let me know if you want early feedback on this or whether we first want to settle on the new LAF.
As I mentioned in comment #5, I think that instead of a Firefox-like toolbar, which contains fields that can steal the focus from the editor, it would be better to leverage the existing "Incremental Find" and "Rename in File" features. The screen real estate used by these is the status bar and the editor, which are displayed anyway, so no need to sacrifice screen space or re-adjust the window layout. I think that would provide for a smoother editing experience anyway, since there are no mouse operations involved at all. What I imagine is: 1) I press Ctrl+F to initiate incremental find mode. 2) As I type each character, the current selection of the editor moves to the next occurrence of the search string, AND highlights all other occurrences at the same time. 3) I can press DOWN to skip forward, or UP to skip backward to other occurrences. If I just want to replace one or more (but not necessarily all) occurrences: 4) I press Enter to switch to single replace mode. 5) I type the replacement text. As I type each character, the other occurrences found remain highlighted but do not change, and the currently selected occurrence is replaced with the characters I type. 6) To replace further occurrences, I use DOWN/UP to skip forward/backward, and Enter to replace any selected occurrence as I go. 7) When I want to stop the incremental find/replace at any time, I press Esc. If I want to replace all the occurrences at once: 4) I press Ctrl+H to switch to replace all mode. 5) I type the replacement text. As I type each character, all the occurrences found are replaced with the characters I type. 6) If I change my mind and don't want the replace to complete, I press Esc. 7) If I want to keep the replaced text, I press Enter. I'll create a state diagram to better describe the "modes" and how to move between them.
Created attachment 73711 [details] State Diagram describing comment #14
Created attachment 73733 [details] GUI in progress (1) I'm attaching 3 images about the current form of the GUI.
Created attachment 73734 [details] GUI in progress (2)
Created attachment 73735 [details] GUI in progress (3)
Created attachment 73736 [details] GUI in progress (4)
In current form of the GUI, I tried to offer Find/Replace facilities to the user at the same time, assuming they'll use set the options in the beginning of usage scenario. (see. GUI in progress(1) ) First I considered adding an "Options" button to display a dialog that'll contain Scope and/or search options like Incremental,Whole Word etc. I'm still considering this approach but I made an effort to hold these options in the bar. ( see. GUI in progress(2) ) The first bar that holds Find/Replace fields and buttons (1) doesn't cause too much trouble when the editor has less area. (see. GUI in progress(3) ) However, the end of the "Options" bar can become invisible if this is the case. (see. GUI in progress(4) ) I'd like to hear any opinions about displaying a Dialog for the Options or iconizing "Incremental Search", "Whole Word", "Wrap Search" etc. options in order to increase Option bar's visibility. By the way, I can implement Will's usage scenario with the current Incremental Find at the Status bar or with this new form. I'm thinking of including a "Highlight All" parameter in Options so expect more soon.
I forgot to mention another idea: I also thought of combining search options (excluding Scope) in a Combo and have a common checkbox for options in the Combo near it. This will increase the mouse clicks to adjust options by +2 ( first Click on Combo, click on option and finally click on checkbox - totals 3 clicks ) However, it will save a good amount of space (for other future options) and would fit in a small area. Keyboard shortcuts ( Alt+I etc. ) would still be valid. What do you think?
Created attachment 73740 [details] GUI in progress (5) - Option Combo style Here's the application of Option Combo style.
(In reply to comment #20, #21 and #22) My take: keep the most common operations simple with as few options a possible and sensible defaults (which is not the case for defaults today) to allow for pervasive serach. Find a way to make more complex operations possible, and that could be delegated to the existing dialog, which as API is here to stay anyway. So simple made easy, and complex made possible. But that is just my opinion.
After Eugene's comment (http://eclipse-soc.blogspot.com/2007/07/status-improving-eclipse-search_12.html) and Comment #23, I'm starting to think that the following will be the best: - Ctrl+F displays this under the editor: 1. "[x] Find: [_____] [Next] [Previous] [Options...] where "Options..." would simply open regular search dialog." This Find bar functions like Firefox Find bar. A "Highlight All" button may be (probably) added. - Another shortcut (like Ctrl+R ? ) switches to a Replace bar like this: 2a. [x] Replace with: [_____] [Next] [Previous] [Replace] [Replace All] [Options...] where "Next" Replace/Finds (from current terms) in forward direction, "Previous" Replace/Finds in backward direction. Default replace/find direction will be forward for this, too. or alternatively 2b. [x] Replace with: [_____] [Next] [Previous] [Replace All] [Options...] eliminating "Replace" in current Dialog. However, since replaces get hard to track with Replace/Find, (2a) may be better. 3. We may still use the current dialog for Replace, just like we use it for "Options..." . And for Will's "incremental replace" request, we may also include a checkbox for that in options group. I need to hear more about these choices from the community.
For the RCP development part wouldn't it be an idea to let the developer decide where he wants to place the widgets (coolbar, statusbar, separate view or editor). I think the search shouldn't be bound to file-search only. A RCP can work with Beans only that are persisted in a database, so no file-search is neccesary but a database-request. If I want pervasive search in my RCP it could be possible to search for customers, orders. In this case I would prefer to have the search-widgets not in an editor, but on a more public place.
I'm OK with using a toolbar (as opposed to status bar) so long as the entire functionality can be accessed using the keyboard - no mouse. That way, the user has the option of using the mouse if they want to or haven't learned the keyboard shortcuts. Probably a good idea to include tooltips on the buttons, so the user is told about the keyboard shortcuts whenever they use the mouse. I definitely agree with comment #23 in that the interface should be kept as simple as possible, and I think Cagatay's approach in comment #24 addresses that nicely. That is, using a keyboard shortcut to switch between the toolbar modes, similar to the state transitions I described in comment #14, models the user's workflow very well. I don't think it's necessary to include options for "Case Sensitive", "Wrap Search", "Incremental", "Highlight All", etc. on the toolbar. Since this is a proposal to replace the current Incremental Find feature, case-insensitive, wrapped, and incremental are implied. As for "Highlight All", the highlight colour should be controlled in Window>Preferences>General>Editors>Text Editors>Annotations, so if the user prefers not to highlight occurrences, they can de-select the "Text as" option there. In addition, they can choose to show occurrences in the Overview ruler and Vertical ruler also. Support for regular expressions and database-persisted beans sounds nice, but I think they are beyond the scope of this proposal - at least for the first version. I like the idea of being able to switch to a more advanced search in the existing Find/Replace and Search dialogs by clicking an "Options..." button. This enhancement should be limited to a fast, smooth all-keyboard way to do find/replace within the current file. Another advantage of Cagatay's "Options..." button idea is that if the existing Find/Replace/Search dialogs are enhanced in future versions of Eclipse, users of the toolbar will have access to those new features too, without making the simple/common use case (ie. "I just want to search for some text and replace it") overly complicated.
>My take: keep the most common operations simple with as few options a possible >and sensible defaults (which is not the case for defaults today) Could you explain what's wrong with the current ones and which ones you find better? For me the most common thing I do with the Find/Replace dialog is replace because I use incremental find without getting a dialog. Cagatay, the combo based solution puts too much overhead for the user. Re comment 24: I like the approach to first only show the Find related UI but there must also be away to start a replace with one command (menu & shortcut) as it is now. I don't like that we still need the old dialog. Either we provide a new and better story or we leave it as is. Showing the Find section on Ctrl+F is OK but then it must also offer new/better UI to customize the options and replace text (e.g. by pressing Ctrl+F a second time). >- Another shortcut (like Ctrl+R ? ) switches to a Replace bar like this: We should reuse Ctrl+F as we do e.g. with Ctrl+O where a second Ctrl+O gives you more power. However, offering a shortcut to directly start a replace is also needed. But you can imagine that all good shortcuts are taken since a long time ;-) Re comment 25: don't mix the workspace search (Ctrl+H) with the Find/Replace in textual editors which this bug is about. If you want a generic search field then this needs to be addressed by either Platform Search or Platform UI. Let this bug be the one who improves Find/Replace in text editors i.e. replaces the Find/Replace dialog and incremental search with something better. >I'm OK with using a toolbar (as opposed to status bar) so long as the entire >functionality can be accessed using the keyboard - no mouse. Of course the new solution will have to work with just the keyboard. I could imagine that the new Find section would be too intrusive for current Ctrl+J (Incremental Find) users as it messes with the editor real estate. Of course if it is already visible it could be used instead of the status line. >Since this is a proposal to replace the current Incremental Find feature Not just that. It must also get rid of the Find/Replace dialog. Actually that's the more pressing one for me.
(In reply to comment #27) > We should reuse Ctrl+F as we do e.g. with Ctrl+O where a second Ctrl+O gives > you more power. However, offering a shortcut to directly start a replace is > also needed. But you can imagine that all good shortcuts are taken since a long time ;-) I agree that reusing Ctrl+F saves shortcuts and is consistent with other reused shortcuts, but we need to be careful. Reusing Ctrl+O simply expands the scope of your outline search; but in this case reusing Ctrl+F switches from a non-destructive to a destructive action. As long as Esc cancels the replace and restores the original text I guess it's OK. But since you are talking about another shortcut to go directly to replace, then you may as well keep it consistent and have that shortcut be the one that switches from find mode to replace mode... no? And on the subject of going straight to replace mode, I assume you are thinking of making the current selection be the search string, so the user can skip the incremental find step? If so, I think that would be very useful. > >Since this is a proposal to replace the current Incremental Find feature > Not just that. It must also get rid of the Find/Replace dialog. Actually > that's the more pressing one for me. Refer to my comment #26 - If the Find/Replace dialog is removed altogether, then all the checkbox options (including regex) need to be crammed into it somehow. I really don't think regex is useful for incremental search... what do you think? I think it makes sense to keep the incremental find/replace as simple as possible, and to provide the option at any time to switch to the "advanced" Find/Replace dialog to take advantage of the functionality there (including functionality which will be added to the Find/Replace dialog in the future). I am concerned that if we attempt to replace the Find/Replace dialog altogether, then the incremental find/replace feature will slowly get ruined by people who would otherwise have added functionality to the Find/Replace dialog. As for whether we use a toolbar-like interface (like Firefox) or continue to use the status bar (like the current Incremental Find): The main disadvantage to the toolbar approach is that it uses screen real estate. Another disadvantage I see from a design standpoint is that it's too easy to add stuff to it without thinking about the keyboard. Also it removes focus from the editor. The main advantage of the toolbar is that it opens up the possibility to replace the (currently awful) File Search feature as well. I'll attach a mock screenshot based on Cagatay's samples to show what I mean. Which gives me an idea - what if the *incremental* find/replace is done on the status board as a pure keyboard-only feature, and the existing Find/Replace dialog and File Search dialog are replaced by Cagatay's toolbar? Best of both worlds?
Created attachment 73910 [details] Mock screenshot of toolbar as replacement for Find/Replace dialog and File Search dialog
>I assume you are thinking >of making the current selection be the search string, so the user can skip the >incremental find step? If so, I think that would be very useful. Yes, and so that the user does not have to execute two action in order to get the replace UI. >The main disadvantage to the toolbar approach is that it uses screen real >estate Correct. That's why I use Ctrl+F only to replace stuff. >Which gives me an idea - what if the *incremental* find/replace is done on the >status board as a pure keyboard-only feature, and the existing Find/Replace >dialog and File Search dialog are replaced by Cagatay's toolbar? Best of both >worlds? Exactly.
> I don't think it's necessary to include options for "Case Sensitive", "Wrap > Search", "Incremental", "Highlight All" Do you mean that "Wrap" and "Highlight All" should usually be turned on? With two improvements, this could be very useful. 1. Eclipse should flash a brief notification when the search wraps. 2. When highlighting all, the current match should be highlighted differently from all the other matches (perhaps the other matches could simply be outlined). With these two changes, would there be anybody in the world who would ever want to run with these features turned off? As far as "Case Sensitive", I personally find insensitive searching to be useless. There's a huge difference between Stream and stream (unless you're writing Pascal I suppose). Without case sensitivity, it's just too tedious to wade through all the false matches just to find the match I want. So, if case-sensitive incremental search is not on by default, then I hope that there is at least provide an option to turn it on. It would make incremental search far faster and easier for me to use. > I really don't think regex is useful for incremental search... Really? It sounds incredibly useful to me! Imagine being able to see exactly what your expression matches as you type it. Heck, this sounds so useful that I could see people using this feature to develop their regexes! Personally, I would love this. Why don't you think it would be useful?
Hi Cagatay, this item is still assigned to you. Any plans to work on this?
Yes, I'm planning to work on this in July. (In reply to comment #32) > Hi Cagatay, this item is still assigned to you. Any plans to work on this? >
Just fyi, Owen, our summer of code student, implemented find for the form-based task editor. For reference see the last screenshot at: http://wiki.eclipse.org/Mylyn/SOC/A_Wiki_Integrated_Task_Editor
*** Bug 98653 has been marked as a duplicate of this bug. ***
*** Bug 99287 has been marked as a duplicate of this bug. ***
*** Bug 496276 has been marked as a duplicate of this bug. ***
*** Bug 43040 has been marked as a duplicate of this bug. ***
