eclipse-platform
Find/Replace Overlay: unable to selectively replace using the keyboard
The old Find/Replace dialog supported the following workflow:
- open a file with many occurrences of one pattern to be replaced
- open the dialog and type search string and replacement
- keep looking only at the editor
- using the keyboard quickly decide between
- replace currently highlighted occurrence
- find next to skip replacing this occurrence
In a recent build (Build id: I20241024-1800) on linux, both actions are said to be bound to Enter, but separate keybindings for find next and replace are needed for the above workflow.
Just to understand the issue correctly: is this a regression within the existing dialog or is this a drawback in functionality of the overlay compared to the dialog?
In addition, can you explain the workflow with the existing dialog in a bit more detail? I have to admit that I am not sure how this works (i.e., which key bindings allow to do this):
using the keyboard quickly decide between
- replace currently highlighted occurrence
- find next to skip replacing this occurrence
On the contrary, this workflow should work fine now with the overlay (starting from yesterday, as the according fix #2405 was merged two days ago): when the replace input field has focus, pressing "enter" performs a replace operation and CTRL+K performs the ordinary "find next" action. If I am not mistaken, the latter was not possible with the dialog, because the editor shortcuts (like CTRL+K) were not passed from the separate dialog shell to the editor.
Thank you for further input!
Just to understand the issue correctly: is this a regression within the existing dialog or is this a drawback in functionality of the overlay compared to the dialog?
The latter. I.e., the out-of-the box experience is worse, I had to search for an option to get the old dialog back just to answer your questions below. A button in the overlay could have helped, to get the old functionality back (just like inline rename refactoring in JDT still has a way to open the original, feature rich dialog).
In fact, with remaining differences I'd love to dynamically select which UI better suites my usecase without having to drill into preferences.
In addition, can you explain the workflow with the existing dialog in a bit more detail? I have to admit that I am not sure how this works (i.e., which key bindings allow to do this):
using the keyboard quickly decide between
- replace currently highlighted occurrence
Alt+d (for Replace/Fin&d )
- find next to skip replacing this occurrence
Alt+n (for Fi&nd)
On the contrary, this workflow should work fine now with the overlay (starting from yesterday, as the according fix #2405 was merged two days ago): when the replace input field has focus, pressing "enter" performs a replace operation and CTRL+K performs the ordinary "find next" action.
I'll try that but let me mention that keeping Alt depressed and typing a staccato of d and n I was quite fast for mass changes. The combination of Enter and Ctrl+K looks clumsy by comparison.
Okay, so the workflow was realized via the existing mnemonics for the buttons. Thank you for the clarification! I agree that this workflow was "smoother" with the existing dialog, so maybe we can find some enhancement that makes the overlay better support this workflow. I've added it to the list of issues in the umbrella issue #2021. Would be great to know if this is a relevant workflow for a significant number of users.
The latter. I.e., the out-of-the box experience is worse, I had to search for an option to get the old dialog back just to answer your questions below.
I disagree with this one. There are still several points that should be improved with the overlay, but the general statement that "the out-of-the box experience is worse" is contrary to the feedback I have noticed so far. In addition, the option to switch back to the existing dialog should be easy to find: just typing "find" or "search" in the preferences dialog directly leads you to the option, and the N&N also points to it.
A button in the overlay could have helped, to get the old functionality back (just like inline rename refactoring in JDT still has a way to open the original, feature rich dialog).
We had discussed this option in the original issue/PR, but did not add such a button because the overlay was intended to be lean and adding such a switch button for the hopefully seldom case of using it would conflict with that goal. In particular, because the overlay is generally intended to have the same features as the existing dialog. I understand that depending on how much you rely on specific functionality of the existing dialog that the overlay does not provide (yet), having such a switch button might be helpful, but I am not sure whether that holds for the majority or even a significant number of users.
The latter. I.e., the out-of-the box experience is worse, I had to search for an option to get the old dialog back just to answer your questions below.
I disagree with this one. There are still several points that should be improved with the overlay, but the general statement that "the out-of-the box experience is worse" is contrary to the feedback I have noticed so far.
sorry if I was unclear: I didn't mean to say "generally worse", just regarding the workflow we are discussing here. This was just answering your question: that the perceived regression was not between versions of the overlay, but between old and new UI - in this particular regard.
In addition, the option to switch back to the existing dialog should be easy to find: just typing "find" or "search" in the preferences dialog directly leads you to the option, and the N&N also points to it.
I used Ctrl+3 looking for the old dialog and found nothing :) - looking for a preference was only my second thought and typing "replace" in the preference dialog's search box brought me to the preference alright.
A button in the overlay could have helped, to get the old functionality back (just like inline rename refactoring in JDT still has a way to open the original, feature rich dialog).
We had discussed this option in the original issue/PR, but did not add such a button because the overlay was intended to be lean and adding such a switch button for the hopefully seldom case of using it would conflict with that goal. In particular, because the overlay is generally intended to have the same features as the existing dialog.
I agree, this is different from inline rename refactoring.
So, if in the end the overlay does all that the old dialog did, and is always easier to use, then of course no more switching is necessary (once old users like me accept the need to change some habits :) ).
How about adding a "skip this occurrence" button on the replace bar with keybinding Alt + Enter? I do see how this is a valuable workflow to support.
I for the most part almost exclusively use "replace all" or "replace all in an area", I almost never have any use for "selectively only replaceing some". Can you come up with some example when that is especially useful?
How about adding a "skip this occurrence" button on the replace bar with keybinding Alt + Enter? I do see how this is a valuable workflow to support.
:+1:
I for the most part almost exclusively use "replace all" or "replace all in an area", I almost never have any use for "selectively only replaceing some". Can you come up with some example when that is especially useful?
Well, every string pattern to be replaced in lots and lots of places is at risk to accidentally match in unintended places, no? :)
My latest use case was: replace any like this:
SOME FLAG ?
someExpression including line comments and whatnot
: null,
with
someExpression including line comments and whatnot
,
Which I did in two iterations as I didn't want to fiddle with multi-line regex etc.
The second iteration replacing ": null" with "" found several matches in unrelated code. Those I had to skip.
Should I use the search & replace dialog instead? Perhaps, but then stepping through all suggested replacements and deselecting unwanted ones didn't feel very fluent to me. So I chose find & replace.
I don't exactly remember other situations, but it's a fairly frequent workflow for me.
Hi,
... pressing "enter" performs a replace operation and CTRL+K performs the ordinary "find next" action.
A good solution would be to modify these key bindings, though there are some issues with the current functionality.
- On the new overlay, the tooltips for the Search forward (Enter) button and the Replace (Enter) buttons suggest that the binding for both is Enter. One of these should be Ctrl+K (or whatever it's rebound to), and both of these should be rebindable.
- Only Ctrl+K (Find next), and not Enter (Replace) can be rebound in Preferences > General > Keys.
- The 'In Windows' context for the Ctrl+K / Enter bindings could be replaced with a new context that's active whenever the Find/Replace overlay is open for the current editor. This'd reduce binding clashes. For example, I've bound F3 to replace Ctrl+K, but have had to unbind the other F3 uses.
When using Ctrl+K and Enter, replacing only certain entries using keyboard shortcuts isn't possible without the mouse:
- With the cursor in the Replace box, Ctrl+K to find next doesn't work. One needs to click back to the editor first.
- Having found a match by clicking in the editor and hitting Ctrl+K, the enter key inserts a new line, rather than replacing.
- It takes 9 tabs to change focus from the Find box to the Replace box. Could we change the tab index to insert the Replace box after the Find box?
- I'd suggest that hitting Enter when anything in the overlay is focussed would move the cursor to the first match in the editor. Subsquent "Enter" presses should then Replace & Find next, and Ctrl+K presses would just Find next.
Ideally one would be able to replace the nth-next occurrence of "Hello" with "World" using the keyboard with, for example: Ctrl+F; "Hello"; Tab(x1); "World"; Enter; Ctrl+K (x n-1); Enter.
