Community
Participate
Working Groups
Orion 0.2M6 I really miss the Find/Replace feature from Eclipse desktop. Having this would make the self-hosting experience much nicer.
This feature would be great for the next release.
See Bug 345033
initial draft was checked in with fd79e4aec282957b2999160d8824f86da726f0ca. You can now find , replace and replace/find in an optional tool bar underneath the normal page tool bar . 1.Hit ctrl+F will toggle the tool bar. 2. You can also close the tool bar at the very right of the tool bar itself. When the tool bar is on, CTRL+K and CTRL+SHIFT+K still works as find next/previous as short cut. Things not done yet but in the plan for M1: 1.Options UI, like : (forward/ backward), (case sensitive/not), 2.Replace all Things not done yet but nice to have for M1: 1.Whole/Selected range , including the tricky styling against the editor selection style 2.High-light all the found results. 3.All other options we are missing from Eclipse desk top
Looking good. A few comments about keyboard interaction: 1. Pressing Ctrl+F while the Find Toolbar has focus should not trigger the browser Find. 2. Pressing ESC while the Find Toolbar has focus should hide the toolbar. 3. Pressing ENTER while the find input field has focus should do "Find Next" 4. Pressing Ctrl+F while the editor has focus and the Find Toolbar is already open should copy the current editor selection into the find input field. I'd like to hear other people's feedback too (or am I the only one who uses the keyboard? ;)
(In reply to comment #4) > Looking good. A few comments about keyboard interaction: > > 1. Pressing Ctrl+F while the Find Toolbar has focus should not trigger the > browser Find. > 2. Pressing ESC while the Find Toolbar has focus should hide the toolbar. > 3. Pressing ENTER while the find input field has focus should do "Find Next" > 4. Pressing Ctrl+F while the editor has focus and the Find Toolbar is already > open should copy the current editor selection into the find input field. > > I'd like to hear other people's feedback too (or am I the only one who uses the > keyboard? ;) Thanks for Mark's comments. He had a quick try on the second draft. Second draft was checked in with cb2b53bc318ac5b6c40c230464041b48ebfdd7b6. Find next, find prev and replace are the only buttons visible in the search tool bar.All other options go to the options pull down menu with check boxes. you can now do : Case sensitive, wrap search, incremental, regular expression, find next after replace. Replace all is not in yet. Whole word search is not in yet.
I added my rants here Bug 353940 (for some reason I thought this bug has been closed)
"I have just tried the new find replace feature and i think it could be made better. the first problem i noticed is that the find text entry *does not* take focus after I press Ctrl+F. This means that I have to take the hand off the keyboard and grab the mouse to click on the text entry to start typing. Second, the entry does not handle default action, hit [enter] when the find entry is on focus does nothing. Third, is not clear that I need to click on the link "find:" to find. Besides that, the link "Replace with" is a no op (maybe it should not get the underline during mouse hover?), and the last link "Replace/Find" is actually just replace. Note that the current find does not address any of the features requested in bug 345033. As for the UI, I'm glad you did not use a dialog, that said, - do you need to add another bar to the top ? could you use the same bar that the "Save" link is located ? - instead of resizing/relayouting the page to add the search bar did you try to use a float div ? we could slide it from the top or from the side using css3 I suspect." (moved my comments here and closed Bug 353940)
more rant: the current version of find replace is unusable open a file (textView.js in my case) hit Ctrl+f type "lineHeight" lineH is input in the search field eight is input in the editor! somehow the second stroke after the shift key causes the focus moves from the search back to the editor.
(In reply to comment #7) > the first problem i noticed is that the find text entry *does not* take focus > after I press Ctrl+F. This means that I have to take the hand off the keyboard > and grab the mouse to click on the text entry to start typing. It was fixed in the latest code. > Second, the entry does not handle default action, hit [enter] when the find > entry is on focus does nothing. This is a TODO in my list, will be released in next commit. > Third, is not clear that I need to click on the link "find:" to find. Besides > that, the link "Replace with" is a no op (maybe it should not get the underline > during mouse hover?), and the last link "Replace/Find" is actually just > replace. In the latest code , there is find next and find previous icon on the right side of the text field. Also, the replace/find is removed.When you replace, there is an option "find after replace", by default this option is off. I may want to put this on as default. Another TODO. > > Note that the current find does not address any of the features requested in > bug 345033. In the latest code, all the features are there except the whole word, replace all and selected range search. Replace all is planned for M1. We will do whole word and selected range after M1. > > As for the UI, I'm glad you did not use a dialog, that said, > - do you need to add another bar to the top ? could you use the same bar that > the "Save" link is located ? We can move to the same tool bar, but for M1 we will just keep the second bar. > - instead of resizing/relayouting the page to add the search bar did you try to use a float div ? we could slide it from the top or from the side using css3 >I suspect." Talked to Mcq about this, it looks cool but the down side of it is that we may hide some editor's contents slightly. After M1 we will have to figure out a generic way to contribute to the tool bar and find/replace will the first contributor.
(In reply to comment #8) > more rant: the current version of find replace is unusable > open a file (textView.js in my case) > hit Ctrl+f > type "lineHeight" > > lineH is input in the search field > eight is input in the editor! > > somehow the second stroke after the shift key causes the focus moves from the > search back to the editor. Mark found the issue as well, fixing it now. The reason was because the editor is racing focus with the find string.
> Talked to Mcq about this, it looks cool but the down side of it is that we may > hide some editor's contents slightly. Indeed, but chrome did it and it looks good (IMO) note that they move the search bar so that it never hides the highlighed text. Other thing you sould look into is the <input type="search">, see http://diveintohtml5.org/forms.html not saying is the right UI for us, but I think it is worth a try.
(In reply to comment #11) > > Talked to Mcq about this, it looks cool but the down side of it is that we may > > hide some editor's contents slightly. > > Indeed, but chrome did it and it looks good (IMO) > note that they move the search bar so that it never hides the highlighed text. > > Other thing you sould look into is the <input type="search">, see > http://diveintohtml5.org/forms.html > > not saying is the right UI for us, but I think it is worth a try. I read the article, seems interesting. Will try it is time is left in M1.
(In reply to comment #10) > (In reply to comment #8) > > more rant: the current version of find replace is unusable > > open a file (textView.js in my case) > > hit Ctrl+f > > type "lineHeight" > > > > lineH is input in the search field > > eight is input in the editor! > > > > somehow the second stroke after the shift key causes the focus moves from the > > search back to the editor. > > Mark found the issue as well, fixing it now. > The reason was because the editor is racing focus with the find string. Fixed this and checked in with ef426c36f477c32cc296f1563ecf017e6bd153c8.
6. I noticed that Ctrl+K (Find Next) and Ctrl+Shift+K (Find Previous) don't work when the Find Toolbar has focus. This makes it hard to iterate through the matches. Also, how do people feel about supporting the FindNext/FindPrevious hotkeys while the Find toolbar is hidden? The desktop Eclipse allows this, and I sometimes use it to continue searching after I've dismissed the Find dialog.
(In reply to comment #14) > 6. I noticed that Ctrl+K (Find Next) and Ctrl+Shift+K (Find Previous) don't > work when the Find Toolbar has focus. This makes it hard to iterate through the > matches. TODO: Actually we should transit all the ctrl+key event to the editor, because the ctrl+key is not useful in the find or replace text area. > > Also, how do people feel about supporting the FindNext/FindPrevious hotkeys > while the Find toolbar is hidden? The desktop Eclipse allows this, and I > sometimes use it to continue searching after I've dismissed the Find dialog. TODO: We should enable this.
(In reply to comment #14) 6. > Also, how do people feel about supporting the FindNext/FindPrevious hotkeys > while the Find toolbar is hidden? The desktop Eclipse allows this, and I > sometimes use it to continue searching after I've dismissed the Find dialog. Fixed it with 4351bf41739382eae57d6d6c9bc0b36d65a94cb2. Also added the replace all function. Now all the M1 functions are there. We are still missing: 1. the whole word search 2. the selected range search 3. the markers for all founds But they are planned as post M1. I will focus on key event handlings next week(e.g. transit all the ctrl+key event to the editor), again here are the TODO's : 1. Pressing Ctrl+F while the Find Toolbar has focus should not trigger the browser Find. 2. Pressing ESC while the Find Toolbar has focus should hide the toolbar. 3. Pressing ENTER while the find input field has focus should do "Find Next". Other TODOs : 1.Revisit default values of options.(e.g. Default option "find after replace" to true.) 2.Consider the <input type="search">, http://diveintohtml5.org/forms.html, as Felipe mentioned. 3.Place hold the default find and replace strings if they are empty.
(In reply to comment #16) Just commit the change with eca722989a01aa0a961572ae537ed6bbf1a7eba1. > 1. Pressing Ctrl+F while the Find Toolbar has focus should not trigger the > browser Find. Done. > 2. Pressing ESC while the Find Toolbar has focus should hide the toolbar. Done. > 3. Pressing ENTER while the find input field has focus should do "Find Next". Done. You can also hit shift+enter to do back word search. > Other TODOs : > 1.Revisit default values of options.(e.g. Default option "find after replace" > to true.) Done. > 2.Consider the <input type="search">, http://diveintohtml5.org/forms.html, as > Felipe mentioned. > 3.Place hold the default find and replace strings if they are empty. Move to M2. Also you can hit CTRL+k when the search text filed gets focus. It will find next in the editor, while keeping the focus on the tool bar. The feature planned for M1 is done, so I am closing this bug now for M1. If any one finds any bug, please open a new one.
when the search bar is already open, Ctrl+F will *not* set focus in the search input. Steps: Ctrl+F to start a search, click back in the editor without closing the search bar press Ctrl+F again actual: nothing happens expected: search input box to get focus
(In reply to comment #18) > when the search bar is already open, Ctrl+F will *not* set focus in the search > input. > Steps: > > Ctrl+F to start a search, > click back in the editor > without closing the search bar press Ctrl+F again > > actual: > nothing happens > expected: > search input box to get focus Good point. Fixed with 88bcb9aee920713f1841979f473b65ac023c7680. Also, we always highlight the text field as selected when switch focus from editor.
added find and replace input text place holder with d7a9c17cc5534ff0635b4099fe894a80bfdd7090
