Proposal: modern and well-integrated Find/Replace

[Wittmaxi]

Proposal: modern and well-integrated Find-replace

Proof of concept here

Problem

User-Interface

The current solution opens a Modal on keypress Control + F - prompting a user to enter a string for finding and optionally a string to replace the currently found string with.

The status quo also has multiple options for searching which are available by selecting the appropriate checkbox.

• The modal can be disturbing while programming
  • The modal requires a switch to a new window
  • The modal can hide important controls while open
  • It is not clear which View the Find/Replace-Dialog is bound to. This becomes an issue, when two editors are opened side-by-side.
• In many cases, the user "just want's to search", not needing too many options. I personally really like using vim's search feature for it's simplicity.
• Searching forward and backwards requires to select the correct radio button and then pressing "search" - which is not intuitive and hindering in many workflows

Integration

A lot of views currently don't provide a Find/Replace functionality. The Find/Replace-Dialog binds to them but will not perform any actions. Furthermore, the Interface of the Find/Replace-Functionality using IFindReplaceTargetExtension is rigid and taylor-made for Editor-Views only.

Solution

The solution will 1) provide a mechnism for ViewParts to register their own find/replace providers 2) provide an alternative UI for the search-functionality that uses an inline-control rather than a dialog (see the PoC screenshot above) 3) Provide a way to choose between the old dialog and the new solution

The new solution aims at being enabled by default in some products such as the IDE. It is up for discussion wether the implementations should have a button to swith to the other representation (i.e., to modify the preference)

Look and Feel

Design goals

The new Dialog should be well integrated, within the workbench and not on top. Additionally, the Dialog should be very easy to use quickly and not feel like a burden to use.

Design Options

I have opted for integrating the search-bar on the bottom of the editor (like IntelliJ does). There is an option to implement the Dialog as a subtle overly to the view (like in VSCode). This can be discussed in the exploration phase of this Proposal.

Concrete Proof of Concept

The Design is not definitive and can be discussed. The Icons will be replaced to fit into the general Eclipse-Theme

The proposed solution consists of an inline-search bar, that pops up from below the text-editor.

1) input bar - active by default when pressing Control + F , automatically highlights the occurrences in the text while the user types (like the behaviour in VSCode. The exact behaviour requires discussion; "searching all occurrences" can create performance problems on larger files). If Text is selected when the inline-dialog is started, the content of the selection is entered into this field by default. When pressing ⏎ Enter, the next occurence is found, in the direction specified by the buttons 3 and 4 2) The amount of occurrences in the current text 3) "Search up": performs a single search up and sets the search direction (for ⏎ Enter) 4) "Search down": performs a single search down and sets the search direction (for ⏎ Enter) 5) "Search whole word": toggles 6) "Case sensitive search": toggles 7) "RegEx search": toggles 8) "Open replace-dialog": toggles

1) Input bar for replace 2) Replace next occurrence (direction defined by the arrows from the search bar) 3) Replace all 4) Toggle replace dialog off

Additional

As a proof-of-concept, the same dialog was implemented for the Problems View to show that this feature can easily be extended to other views. The Problems-view does not allow for replacing, for example, so the search-bar does not show that as an option.

As part of the interface-design, each view can optionally specify which "search providers" it supports (See Search-providers), if it wants to provide a search-functionality.

Design (Engineering)

The old Dialog

Part of this proposal is extracting the business-logic of the old Find/Replace-Dialog and sharing it with the new inline visualization. This brings the following advantages: 1) Both visualizations behave consistently - improving clarity in usage 2) Both visualizations benefit from the same bugfixes and improvements

Search-providers

Each view should be able to specify it's search-providers and it's search-options. When opening the FindReplace-popupbar, the the bar will request the viewpart for search providers and a UI-renderer from the viewpart. It is likely tha tthe UI-Renderer will be shared across most views while the functional search provider will depend on the view type.

Further ideas

More search options

• A new search-option could be added to perform an AST-search on a Java-file
  • This benefits from allowing multiple search-providers that are specific for each view
  • This is not part of this proposal and not necessarily a wanted feature, instead highlighting the new flexibility gained by introducing search providers.

Inline-toolbar

This proposal introduces an "inline popup toolbar", which can later be used by other features which are currently implemented as modals, for example a new refactoring. Views that provide support for such an inline toolbar, can inherit from IInlinePopupToolbarProvider which specifies functions for creating the toolbar composite and closing it.

[mickaelistria]

I strongly support this initiative! However, if we want progress here, we should try to find simple and safe milestones/increments.

The integration in the view/editor/part seems to be relatively intrusive: I supsect it requires change to more than the Search dialog, so I would defer that part for later. However, the proposal to have an overlay "Search bar" (which is more or less a relayout of a subset of the Search dialog) is a great one; as it's still relatively independent from the host part in term of rendering. For some time, we also need to keep the Find/Replace dialog accessible: a preference could control which variant (dialog vs bar) to use. The Search dialog could show an extra action to "switch to search bar" and vice-versa to facilitate the switch.

[mickaelistria]

At this stage, I would encourage you to submit a pull request that contains the very minimal subset available to try this approach out.

[Wittmaxi]

@mickaelistria Thank you for your feedback! I have implemented a MVP on my own fork. Is it helpful if I create a PR against the origin repository?

[mickaelistria]

Yes please, a PR makes it easier to try and review.

[Wittmaxi]

This is the PR!

[vogella]

I very much like this approach. Eclipse search dialog is one of the worst out their and with your change, it looks very modern (and similar to other modern tools).

[Wittmaxi]

For transparency, I want to summarize a conversation with @HeikoKlare which shed light on a fundamental question.

context

It is clear that inserting the find-replace dialog as a composite onto the editor is intrusive and requires a lot of testing before even being considered for merging, however, it is also clearly the final solution if we want to allow other views to provide this functionality. A simple straight-forward solution is to implement a temporary solution for the next release, consisting in the find-replace dialog as a hovering overlay that is anchored and follows the editor when it moves or changes size. This solution cannot be the final solution for all views, but if we limit ourselves to the editor as a first increment, it should be fine. However, an overlay-solution could not look like what the currently displayed solution looks like; it would always hide the last few lines of a text file. If a user wants to search the last few lines of a text-document, they would have to add a few lines, search, and remove the empty lines. Hence, we would need to introduce a second design for the subsequent release (more vs-code-like). In the end, we would have three find/replace dialogs in total, all needing maintenance, since I doubt we could fully get rid of the temporary solution.

I personally would opt for directly implementing this solution correctly, accepting possible delays down the road for testing. I can also understand the calls to caution, asking to first implement a temporary solution (that will likely stay!) and to subsequently implement the final solution - I would like to hear more input on this before committing to any roadmap

With this in mind, I want to present a temporary

Roadmap

Milestone 1

e.g., December 2023

Refactor FindReplaceDialog.java

This class mixes the functionality and the interface of Finding and replacing. To reuse this functionality, I want to extract the business logic into a separate FindReplacer-module which will be reused by the new find-replace-bar. This step will NOT include any logic for polling views for their search-providers

Implement the overlay-based Find/Replace

(subject for debate) I will implement the overlay-based Find/Replace as @mickaelistria suggested earlier. This will entail a different design that looks more like the one VScode currently uses and will incrementally approach a good solution that can be shipped with the December 2023 release.

Milestone 2

e.g., March 2024

Integrate into Layout

Using a new Composite inside of the View (like in the current solution), I will integrate the dialog into the Layout. This will happen as soon as possible, to give us a lot of time to find possible problems in integration.

Poll Views for search providers

Allow each view to give it's own search-providers to the FindReplacer using a new common interface for FindReplace

Implement the Find/Replace functionality in more views

[mickaelistria]

This roadmap seems quite good to me! Although, I wouldn't make the refactoring of FindReplaceDialog a pre-requisite though, and would rather see it implemented as needed; ie while developing the new UI, so it gets clearer of which part to refactor and how. I've had mostly bad experience of "refactoring as a preparation", it usually is more time consuming and leads to worse results than "refactoring as needed".

I don't think you should try to commit to dates and so on; just do your best and we'll integrate it as soon as we collectively agree it is ready to be merged, step by step. The sooner the better, of course; but we don't have nor need particular deadlines.

[wimjongman]

It would be nice to get more lines for the search and replace fields when the find view is in regex mode.

[basilevs]

Replace/Find button in Find/Replace dialog skips every second occurrence. @Wittmaxi could you please check https://github.com/eclipse-platform/eclipse.platform.ui/issues/1540 ?

[Wittmaxi]

Edit: I missed your bug-report. I could reproduce the bug you described in #1540. It looks like @HeikoKlare already issued a solution - did this address your problems?

@basilevs I'm not exactly sure what you are experiencing, can you please give me a few steps to reproduce your issue? (Ideally in a new issue - this one has grown to become quite large)

This is the behavior I am experiencing (walkthrough): setup: first "Find": "Replace/Find": "Replace/Find": "Replace/Find":

From my understanding, this is expected behavior: we replace the currently selected occurence of the word and immediately search for the next so that you can "click through" all occurences with "Replace/Find" and make sure you don't accidentally change something that you didn't intend on changing.

[basilevs]

I did not test solution by @HeikoKlare yet, but I assume that my concerns are covered.