Community
Participate
Working Groups
Created attachment 181491 [details] next/previous search project CTRL+. and CTRL+, work in the search view, but not once the search view loses focus. This is a simple experiment that will activate the search view, go to the next/previous item, and activate the editor. By default it's bound to ALT+, and ALT+. PW
+1 for having this in the standard platform
I've checked this into CVS /cvsroot/eclipse: platform-incubator/ui/other/org.eclipse.ui.navigate.search PW
+1 I've wished this functionality a thousand times!
BTW. is it somehow possible to create a new search result from the current error markers?
(In reply to comment #4) > BTW. is it somehow possible to create a new search result from the current > error markers? You mean taking a set of markers and then having the same information in the search view format, just like a search? I don't think so. But search is pluggable, someone could write that. PW
*** Bug 330325 has been marked as a duplicate of this bug. ***
This is a good start. Could the mechanism be improved/generalized that the same thing works in the Problems view as well?
(In reply to comment #8) > This is a good start. Could the mechanism be improved/generalized that the same > thing works in the Problems view as well? See bug 115202. The general bug is bug 32330.
Also If you pin the search view then pressing the dedicated button should open the latest search view and start finding next
Also open in new tab must be there for search view
(In reply to comment #11) > Also open in new tab must be there for search view I mean in the preference page open in new tab once activated all subsequent search must open in new tabs
I now have this functionality by utilizing a saved keyboard macro with the Emacs+ plugin. I described this implementation at <http://davidmichaelkarr.blogspot.com/2010/10/keyboard-nirvana-with-eclipse-and-emacs.html>.
+1 for having it as standard. This is the thing I miss most from Visual Studio.
When looking at this, please consider how to support this generally across markers and problems. Perhaps it could be the that the next/previous actions simply execute against the last active list view.
Also see this related StackOverflow asking how to do this (for markers in particular) - http://stackoverflow.com/questions/2329438/how-can-i-go-to-the-next-eclipse-marker-e-g-build-error-using-the-keyboard
If someone wants to adapt this so it can go into the Platform I'm willing to mentor them. PW
See bug 115202 comment 13 for a general solution.
https://git.eclipse.org/r/23721
Mass move to 4.7 as M7 is approaching. Please move back in case you are planning to fix it for Neon.
*** Bug 566034 has been marked as a duplicate of this bug. ***
I had a look at how it currently works and how the requested feature could be implemented. Currently: - while the Search dialog is focused, it handles the event(ShowNextResultAction), by opening the file and focusing the editor to the search result. - while the editor is focused, it handles the event (GotoAnnotationAction), by going to the next/prev annotation. - if something else is selected, noting happens. Possible solution: - org.eclipse.ui.workbench.texteditor provides a new extension point: gotoConsumer. - when the GotoAnnotationAction of the editor is triggered, it is first checked if an enabled gotoConsumer is registered. - if no, the event is handled like before. - if yes, the event is delegated to the class defined in the gotoConsumer extension. - org.eclipse.search needs to implement a gotoConsumer. - org.eclipse.search should disable its gotoConsumer if there is no search or if the user deactivated this delegation. All changes of this solution would be in eclipse.platform.text. This component of this ticket could changed to reflect this.
(In reply to Dieter Mai from comment #22) > I had a look at how it currently works and how the requested feature could > be implemented. Great, thank you. Would be great to get a Gerrit from you for this feature. > Currently: > - while the Search dialog is focused, it handles the > event(ShowNextResultAction), by opening the file and focusing the editor to > the search result. > - while the editor is focused, it handles the event (GotoAnnotationAction), > by going to the next/prev annotation. > - if something else is selected, noting happens. > > Possible solution: > - org.eclipse.ui.workbench.texteditor provides a new extension point: > gotoConsumer. > - when the GotoAnnotationAction of the editor is triggered, it is first > checked if an enabled gotoConsumer is registered. > - if no, the event is handled like before. > - if yes, the event is delegated to the class defined in the gotoConsumer > extension. > - org.eclipse.search needs to implement a gotoConsumer. > - org.eclipse.search should disable its gotoConsumer if there is no search > or if the user deactivated this delegation. I assume this could be confusing, e.g., if the user triggered a search a while ago, it would still jump to the next result even if the user now works in the editor. I think Pauls suggestion to offer a new shortcut is less confusing. Maybe we just use a new keybinding for the next search result, as Paul did? > All changes of this solution would be in eclipse.platform.text. This > component of this ticket could changed to reflect this. Done.
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/171742
