Modern and well-integrated Find-replace

[Wittmaxi]

Proposal: modern and well-integrated Find-replace

Proof of concept implemented in my Fork of eclipse.ui

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]

As mentioned on the issue, changing the editors or views layout is a bit too much at the moment.
For a 1st iteration, would it be possible to "just" have an action on the existing Find/Replace dialog that would turn the dialog into a Search bar positioned at best as overlay on the editor?

[vogella]

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

Would it be possible to have individual commits for isolated changes / isolated enhancements? For example, extraction of the search logic so that is can be reused? We prefer to have have isolated commits and it think isolating your changes into smaller commits will make it more likely to get them integrated.

[HeikoKlare]

Thanks for your feedback @mickaelistria @vogella!
Note that this PR is only meant to give an impression of where it might go in the end. We will incrementalize the contributions that are actually intended to be merged into small commits/PRs. That will particularly separate the extraction and improvement of reusable search business logic from improved UI/UX.

[merks]

Hopefully the old dialog also just continues to work. EMF reuses it to support find and replace in structured viewers:

[HeikoKlare]

@merks The existing dialog must remain existant and working anyway, since we we don't know who may uses it for their views. Even if it was possible to replace the old dialog with a new visualization without breaking existing APIs (syntactically or w.r.t. their existing contracts), it is not what you should expect from the Eclipse platform. However, it is also a goal of the new functionality to make views able to define their search provider (like @Wittmaxi has prototyped for the problems view), so that it may even be possible that structured viewers in EMF adopt that functionality easily.

[vogella]

Please get started with creating the first PR which should be merged. Making plans is good, getting started with the integration of new functionality even better.

A good approach is typically to start with desired refactorings which do not change functionality but make the code easier to read and re-use before adding new functionality.

[akurtakov]

What is the status of this one? Should it be closed as #1192 is in now?

[Wittmaxi]

@akurtakov yes!