Community
Participate
Working Groups
Find next action is not enabled after a search in the debug console.
The console currently only contributes a "find" action - not find next, etc. It seems stranget that we have to contribute these actions since the view has a "FindReplace" adapter.
Problem appears in M5, and in this case we do not have Find next on the Edit menu at all.
Deferred
*** Bug 66527 has been marked as a duplicate of this bug. ***
Re-open for 3.1
FYI, Find (^F) doesn't work for me at all in build 200409070800 Console. The Find/Replace... menu item is disabled in the Edit menu.
Find works in HEAD. Find next is still broken.
Found that the "Find" command is enabled "In Windows", and "Find Next" is enabled when "Editing Text". I.e. they have different scopes, and the "Editing Text" scope is not active when the console is active (only when the editor is active).
And, when I enable the "Editing Text" context in the text console, the following appears for process consoles: Conflicting key binding for 'org.eclipse.debug.ui.commands.eof' and 'org.eclipse.ui.edit.text.delete.line'
Filed bug 78357 against text component regarding command scopes/contexts.
Marking as later, requires bug 78357 to be fixed first.
*** Bug 103021 has been marked as a duplicate of this bug. ***
any plans for this. this is a serious problem for me right now. i keep getting annoyed by the dialog
Appears you need to convince the friendly platform text committers to fix bug 78357...we can always blame someone else :-)
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
Yes, this still matters. I would like to reopen this bug, but it seems to be impossible.
.
This still doesn't work in eclipse 4.9.0 If I assign a new binding by copying "Find Next" ans set when to : - In Console View or - Comparing in an Editor or just: - In Windows It still doe snot work, neither in the console view or in an compare editor. (it's been 15 years!)
Unfortunately, we don't have resources to work on this. If some one can provide a quality patch we can look into it.
Though I cannot provide a patch for this bug (yet), I have recently given a try to a couple of implementation options which I'll sketch below. To me it looks like each option works to some extent but also comes with some drawbacks. Maybe someone can have a look and judge which one seems to be the most promising path (or even suggest another approach.) First of all, providing an action implementation for both Find Next/Find Previous commands should be straightforward. The UI Workbench Texteditor plugin thankfully provides an action class FindNextAction which can be utilized in TextConsolePage, similar to how FindReplaceAction is already utilized there. This way, both commands can easily be added to a console's context menu. Unfortunately, for the "Incremental" counterparts of Find Next/Find Previous things do not seem to be just as straightforward. While the Texteditor plugin also provides IncrementalFindAction, this action expects its workbench part to provide an IncrementalFindTarget adapter which, however, is package private. Therefore, this target isn't supported out of the box by TextConsoleViewer and neither by any of its ancestors. (I haven't done any further research in that direction, but bug 66527 most likely will require a more elaborate solution than what is required for Find Next/Find Previous.) Coming back to Find Next/Find Previous, providing them in a console's context menu alone sure will not suffice to meet most user's expectations, I guess (myself included.) We should also provide key bindings for these commands, preferrably CTRL-K and CTRL-Shift-K as in a text editor. Now for this part I find it difficult to go forward without involving other plugins while keeping things backward compatible, and here's why: The current key binding as defined in the Text Editor plugin is restricted to the "Editing Text" scope and thus not applicable to the console's scope. To solve this, I basically see two options: Either enhance these bindings to the "In Windows" scope by removing the contextId from their definition in the Text Editor's plugin.xml. Or, introduce another binding in Console's plugin.xml and restrict it to the console's scope. The first option works fine (as far as I can tell), but may collide with a similar key binding provided in a 3rd party plugin we are not aware of. So we risk to break backward compatibility. The second option will lead to a conflict in the Java Stack Trace Console (similar to bug 566192, I guess) which I assume arises because JavaStackTracePageParticipant activates context org.eclipse.jdt.ui.javaEditorScope which is a descendant of scope org.eclipse.ui.textEditorScope that finally encompasses the conflicting key bindings. I haven't yet researched any further what impact it will have to not activate the javaEditorScope in JavaStackTracePageParticipant. Further options concerning the key bindings, i.e. not providing a binding at all or providing a binding to a different key sequence, seem even less attractive to me. Please apologize if I went too much into detail here; however, if someone is able to provide a suggestion how to deal with the key bindings with a minimal impact, I'm glad to further work on this issue then.
(In reply to Christian Gabrisch from comment #20) > Though I cannot provide a patch for this bug (yet), I have recently given a > try to a couple of implementation options which I'll sketch below. To me it > looks like each option works to some extent but also comes with some > drawbacks. Maybe someone can have a look and judge which one seems to be the > most promising path (or even suggest another approach.) > > First of all, providing an action implementation for both Find Next/Find > Previous commands should be straightforward. The UI Workbench Texteditor > plugin thankfully provides an action class FindNextAction which can be > utilized in TextConsolePage, similar to how FindReplaceAction is already > utilized there. This way, both commands can easily be added to a console's > context menu. > > Unfortunately, for the "Incremental" counterparts of Find Next/Find Previous > things do not seem to be just as straightforward. While the Texteditor > plugin also provides IncrementalFindAction, this action expects its > workbench part to provide an IncrementalFindTarget adapter which, however, > is package private. Therefore, this target isn't supported out of the box by > TextConsoleViewer and neither by any of its ancestors. (I haven't done any > further research in that direction, but bug 66527 most likely will require a > more elaborate solution than what is required for Find Next/Find Previous.) > > Coming back to Find Next/Find Previous, providing them in a console's > context menu alone sure will not suffice to meet most user's expectations, I > guess (myself included.) We should also provide key bindings for these > commands, preferrably CTRL-K and CTRL-Shift-K as in a text editor. Now for > this part I find it difficult to go forward without involving other plugins > while keeping things backward compatible, and here's why: > > The current key binding as defined in the Text Editor plugin is restricted > to the "Editing Text" scope and thus not applicable to the console's scope. > To solve this, I basically see two options: Either enhance these bindings to > the "In Windows" scope by removing the contextId from their definition in > the Text Editor's plugin.xml. Or, introduce another binding in Console's > plugin.xml and restrict it to the console's scope. > > The first option works fine (as far as I can tell), but may collide with a > similar key binding provided in a 3rd party plugin we are not aware of. So > we risk to break backward compatibility. The second option will lead to a > conflict in the Java Stack Trace Console (similar to bug 566192, I guess) > which I assume arises because JavaStackTracePageParticipant activates > context org.eclipse.jdt.ui.javaEditorScope which is a descendant of scope > org.eclipse.ui.textEditorScope that finally encompasses the conflicting key > bindings. I haven't yet researched any further what impact it will have to > not activate the javaEditorScope in JavaStackTracePageParticipant. > > Further options concerning the key bindings, i.e. not providing a binding at > all or providing a binding to a different key sequence, seem even less > attractive to me. > > Please apologize if I went too much into detail here; however, if someone is > able to provide a suggestion how to deal with the key bindings with a > minimal impact, I'm glad to further work on this issue then. Thanks Christian for the details analysis. do give a try to the second option i.e introduce another binding in Console's plugin.xml. No necessary that we hit the "Clear key" issue.
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.debug/+/173471
Here's my proposal for a patch that enables the Find Next, Find Previous commands on a text console. I'd rather consider it a copy&paste of the Find/Replace integration than a quality patch; after all, it seems to do the job. However, there are a couple of shortcomings: For one, as anticipated, when you now open a Java Stacktrace Console, there is a conflict with the CTRL-K, CTRL-Shift-K bindings of the Text Editor context. An error message is printed on the Eclipse console, but the commands still seem to work. I haven't yet investigated any further how to resolve that conflict. Also, I was unable to enable the commands in the Edit menu. They are only available in the console's context menu (and as the aforementioned key sequences, of course.) To me, this is rather a minor issue, but maybe you have an idea what it takes to also enable the commands in the Edit menu. Finally, after increasing the version of org.eclipse.ui.console to 3.10.100 due to a previous build error, Eclipse now complains "The micro version is increased unnecessarily since either major or minor version is already increased". I have to admit I haven't understood the versioning policy in full detail, so your advice will be appreciated here, too. Looking forward to your feedback. I will also provide a (small) update of the reference help once we're done with the implementation.
(In reply to Christian Gabrisch from comment #20) > Coming back to Find Next/Find Previous, providing them in a console's > context menu alone sure will not suffice to meet most user's expectations, I > guess (myself included.) We should also provide key bindings for these > commands, preferrably CTRL-K and CTRL-Shift-K as in a text editor. Now for > this part I find it difficult to go forward without involving other plugins > while keeping things backward compatible, and here's why: > > [...] > Either enhance these bindings to > the "In Windows" scope by removing the contextId from their definition in > the Text Editor's plugin.xml. > [...] > works fine (as far as I can tell), but may collide with a > similar key binding provided in a 3rd party plugin we are not aware of. So > we risk to break backward compatibility. I'm not certain it should be an issue. The bindings (are supposed to) only trigger the commands that are enabled and handled. If the enablement/handling of the command/action is properly handled (I'm not sure it is at the moment), then we could bind to Ctrl+K in Windows and that would only trigger the command in case there is an active handler, and trigger whichever bound command in other cases. So there is no additional risk of collision. However, the big issue is in identifying whether the FindNext action properly updates the underlying command. That trouble is one reason why action are to be avoided nowadays, commands are superior and simpler in everything. So before we merge, I'd like to use this bug as an opportunity to investigate whether we could properly handle enablement for those actions. Is this something you'd be interested to look at?
I think one root issue here is that org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.executeCommand() will try to execute the command even if it doesn't seem handled (obj == null); so the Ctrl+K shortcut would leak to all views independently of whether an action is bound to it or not. If this is indeed a bug and if KeyBindingDispatcher can be fixed, then Ctrl+K would probably work out of the box in the Console view, and we could move the binding to "on Windows" with very low risk of conflict.
(In reply to Mickael Istria from comment #25) > I think one root issue here is that > org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.executeCommand() will > try to execute the command even if it doesn't seem handled (obj == null); so > the Ctrl+K shortcut would leak to all views independently of whether an > action is bound to it or not. > If this is indeed a bug and if KeyBindingDispatcher can be fixed, then > Ctrl+K would probably work out of the box in the Console view, and we could > move the binding to "on Windows" with very low risk of conflict. I kept looking at it a bit, and code says that in case of conflicting bindings (ie Ctrl+K already existing in some views), then the not-handled ones are ignored. So it seems totally safe to just move the Ctrl+K shortcut from "on Text Editor" to "on Windows" here. I would recommend that over duplicating the shortcut definition.
(In reply to Mickael Istria from comment #26) > (In reply to Mickael Istria from comment #25) > > I think one root issue here is that > > org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.executeCommand() will > > try to execute the command even if it doesn't seem handled (obj == null); so > > the Ctrl+K shortcut would leak to all views independently of whether an > > action is bound to it or not. > > If this is indeed a bug and if KeyBindingDispatcher can be fixed, then > > Ctrl+K would probably work out of the box in the Console view, and we could > > move the binding to "on Windows" with very low risk of conflict. > > I kept looking at it a bit, and code says that in case of conflicting > bindings (ie Ctrl+K already existing in some views), then the not-handled > ones are ignored. > So it seems totally safe to just move the Ctrl+K shortcut from "on Text > Editor" to "on Windows" here. I would recommend that over duplicating the > shortcut definition. OK, I will change that accordingly.
(In reply to Mickael Istria from comment #24) > So before we merge, I'd like to use this bug as an opportunity to > investigate whether we could properly handle enablement for those actions. > Is this something you'd be interested to look at? I definitely am. However I'm not yet really familiar with the Eclipse development ecosystem (as you will already have noticed :-)), so I'm a little unsure what the next steps will be right now. Or are all necessary investigations already done with your follow-up comments #25, #26?
(In reply to Christian Gabrisch from comment #28) > I definitely am. However I'm not yet really familiar with the Eclipse > development ecosystem (as you will already have noticed :-)), so I'm a > little unsure what the next steps will be right now. Or are all necessary > investigations already done with your follow-up comments #25, #26? I think comment #25 and #26 covered my main concerns (sorry I was really too curious and couldn't resist looking at it and didn't leave you much chance to do it, I realize it's not very nice...). So if this seems OK to you, I think you can incorporate the conclusion of this comments and the other suggested changes on the Gerrit review.
@Christian: can you please update your patch according to the discussion?
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.debug/+/173471 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.debug.git/commit/?id=a2132c2bbccb736c4f7de11478fdd3505807c2bf
Thanks a lot Christian! Do you also plan to work on the patch in eclipse.platform.text repo to widen the scope of the shortcut?
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/173705
(In reply to Mickael Istria from comment #32) > Thanks a lot Christian! > Do you also plan to work on the patch in eclipse.platform.text repo to widen > the scope of the shortcut? (In reply to Eclipse Genie from comment #33) > New Gerrit change created: > https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/173705 That was fast ;)
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/173705 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=62c114932a72632ed8512e8385576a71e69e99a0
(In reply to Mickael Istria from comment #34) > (In reply to Mickael Istria from comment #32) > > Thanks a lot Christian! > > Do you also plan to work on the patch in eclipse.platform.text repo to widen > > the scope of the shortcut? > > (In reply to Eclipse Genie from comment #33) > > New Gerrit change created: > > https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/173705 > > That was fast ;) Well, thank you for your patient guidance, Mickael :-) Also, please apologize the delayed progress since comment #29. I think what is left to do now is to update the reference help, right? I'll be happy to work on that, too.
There seems to be nothing too specific in the documentation about find in console. So there seems to be no need to change anything there. However, it'd be good to add a note about it in the N&N document from https://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/ , but the 4.19 folder isn't created yet. Either you can create the 4.19 folder by cloning the 4.x-template and adapting it and then add your note to platform.html, or if it works better for you, I'll try to create the 4.19 folder soon and will ping you when it's open for addition.
(In reply to Mickael Istria from comment #37) > There seems to be nothing too specific in the documentation about find in > console. So there seems to be no need to change anything there. > However, it'd be good to add a note about it in the N&N document from > https://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/ , but the 4.19 > folder isn't created yet. Either you can create the 4.19 folder by cloning > the 4.x-template and adapting it and then add your note to platform.html, or > if it works better for you, I'll try to create the 4.19 folder soon and will > ping you when it's open for addition. I created the 4.19 folder, you can add a note in 4.19/platform.html about this new feature.
New Gerrit change created: https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/173725
Gerrit change https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/173725 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=1d284e45924e856d5a59a05e57eb83230314102f
Thanks a lot for this set of high quality contribution Christian! Please keep it on, that's very welcome!
(In reply to Mickael Istria from comment #41) > Thanks a lot for this set of high quality contribution Christian! Please > keep it on, that's very welcome! Thanks again for your kind support, Mickael! It was a pleasure for me. Now, how should we go on with bug 66527? It was marked as duplicate of this one, but providing an incremental find command seems to require a little bit more work than Find Next and Find Previous did (as pointed out in comment #20.) What about re-opening bug 66527 and I'll have a look at it?
Eclipse SDK Version: 2021-03 (4.19) Build id: I20201231-1800 Thanks Christian and Michael!
New Gerrit change created: https://git.eclipse.org/r/c/statet/org.eclipse.statet-ltk/+/188999
Gerrit change https://git.eclipse.org/r/c/statet/org.eclipse.statet-ltk/+/188999 was merged to [master]. Commit: http://git.eclipse.org/c/statet/org.eclipse.statet-ltk.git/commit/?id=61297d4c6ebe6bb7fbf1273a714ef0304bdee2f2
