Fix find focus drifting when output streams into active block#10057
Conversation
When the find bar is open and the active block's output is still streaming, rerun_on_block() splices new matches into the match vector but previously kept raw_focused_match_index unchanged. This caused the highlighted match to visibly jump to whatever text now occupied that numeric position. Fix: before splicing, snapshot the currently focused match. After splicing, relocate it in the updated vector by comparing the match's span identity (block_index, grid_type, range). If the focused match was outside the rerun block's slice, shift the index by the change in match count instead. A new same_span() helper on BlockListMatch compares matches ignoring transient state like is_filtered. Added two regression tests exercising both cases: - focused match inside the active (streaming) block - focused match in an older block while the active block grows Closes warpdotdev#9542 Co-Authored-By: Oz <[email protected]>
|
I'm starting a first review of this pull request. I reviewed this pull request and requested human review from: @seemeroland. Comment Powered by Oz |
github-actions
Bot
added
the
external-contributor
![oz-for-oss[bot]](https://avatars.githubusercontent.com/in/3450139?s=60&v=4){kind=small}
There was a problem hiding this comment.
Overview
This PR preserves find focus across active-block reruns by snapshotting the focused match and relocating it by span identity after refreshed matches are spliced in. The added regression tests cover focus preservation within the streaming block and focus index shifting for an older block.
Concerns
- None.
Verdict
Found: 0 critical, 0 important, 0 suggestions
Approve
Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).
Powered by Oz
seemeroland
left a comment
seemeroland
left a comment
There was a problem hiding this comment.
Nice find and fix - I was able to reproduce the issue and confirm that this branch fixes it locally. Thanks for the contribution!
2 participants
Description
When using cmd+f to search a block whose output is still streaming, the currently selected match jumps to a different piece of text as new matches are appended. This happens because
BlockListFindRun::rerun_on_block()preserves the raw focused-match index when splicing updated matches for the active block — as new matches stream in, the same numeric index points to a different span.Fix: Before splicing, snapshot the currently focused
BlockListMatch. After splicing, relocate it in the updated vector by comparing span identity (block_index,grid_type,range) via a newsame_span()helper. If the focused match was outside the rerun block's slice, shift the index by the delta in match count. Also handles the "no old matches" (new block) case by shifting the index forward.Linked Issue
Closes #9542
ready-to-implement(triaged bug — implicitly ready-to-implement per CONTRIBUTING.md).Testing
Added two regression tests in
block_list_test.rs:test_rerun_on_block_preserves_focused_match_in_active_block— focuses the prompt match inside a streaming block, appends new output with additional matches, verifies focus stays on the same span.test_rerun_on_block_preserves_focused_match_in_older_block— focuses a match in an older finished block, appends output to the active block, verifies the focused match and its UI index shift correctly.All 10 terminal find tests pass.
cargo fmtandcargo clippy -p warp --testspass clean.Agent Mode
Conversation link
CHANGELOG-BUG-FIX: Fixed find (cmd+f) selection jumping to a different match when new output streams into the active block.
-->
Co-Authored-By: Oz [email protected]