Display the count of results in Find/Replace overlay

[elsazac]

Display the total number of results in the Find/Replace overlay .The count is kept in sync with search updates and helps users understand the scope of search results while navigating between matches. The result bar is displayed only when one or more matches are found. When the search returns no results, the result count bar is automatically hidden.

Fixes: #2034

[github-actions]

Test Results

   861 files  ±0     861 suites  ±0   54m 25s ⏱️ + 2m 14s
 8 024 tests ±0   7 781 ✅ ±0  243 💤 ±0  0 ❌ ±0 
20 511 runs  ±0  19 856 ✅ ±0  655 💤 ±0  0 ❌ ±0 

Results for commit 8007e93. ± Comparison against base commit bacf493.

[elsazac]

This is how the overlay looks. It displays the result count alongside the results. When no results are available (ie zero matches present), the sidebar remains hidden.

findreplace.mov

[HeikoKlare]

Thank you for starting to work on this. It's great to see this feature being implemented. I look forward to having this feature available in the platform.

At this point, I have some high-level comments for the current state :

• Appearance: currently, the UI looks quite "busy" in the sense that controls are moving around while typing because of the count display. Most importantly, the options controls move when the input field changes between an empty and non-empty state (i.e., depending on whether the count number is shown or not). I am also not sure if it's good to only show the count number if the input field is non-empty or if there shouldn't always be something displayed for the count, even when the input field is empty, to produce less UI changes during usage (like VS Code does it). What I am also not so sure about is the non-fixed width of the count label. This changes the size of the input field and the position of the drop down all the time while typing. Finally, the count label does never disappear when the size of the overlay shrinks. I think it should disappear together with the option controls:
  
• Performance: if I understand correctly, the business logic for calculating the number of matches is currently executed in the UI thread. This can lead to a significant performance degradation when operating on larger files. I have tested with a 15 MB XML file and it becomes unusable for me, because the count calculation while typing takes so long. To be fair, the existing logic calculations are not super fast in these situations either, but at least they stay somehow usable. So either it must be possible to disable the display and calculation of the match count, to limit the number of matches after which the calculation stops (VS Code also display "19999+" if there are too many matches, probably for both performance and stable label width) or (preferred) the calculation should be done asynchronously.
• Implementation/Design: the business logic for calculating the match count is currently hard-coded into the UI (FindReplaceOverlay). There is already theFindReplaceLogic for the business logic behind find/replace functionality. The according calculation logic has to be moved there for the sake of clean design and also for potentially sharing this functionality with the FindReplaceDialog. Note that the dialog already has a "Select All" functionality, which also includes a match counting. So it might be possible to share code there.
• Tests: The FindReplaceLogic and the UIs on top are well tested, so we should provide tests for such added functionality as well. That could of course also be done later when a more mature state of the implementation is reached, but I wanted to mention this as it can also help during further development to have a set of essential tests early, so that changes/refactorings can be evaluated more easily.

[elsazac]

At this point, I have some high-level comments for the current state :

Appreciate the detailed feedback. There are quite a few points to work through, so I will try to address them one by one and update this as I go.