Avoid eager terminal find result rendering

[hansemannn]

Description

Avoids eagerly materializing and rendering every terminal find result on the block list. The find run now stores only the focused result initially, discovers additional results lazily during navigation, and stops sending full-block match ranges to every block grid for highlighting.

The find bar still reports the total immediately for normal result sets. For very large result sets, the synchronous count is capped at 1000 and displayed as 1000+, avoiding the same main-thread scan that caused hangs with repeated matches such as printf 'Hans%.0s' {1..1000000}.

Closes #7565

Linked Issue

• The linked issue is labeled ready-to-spec or ready-to-implement.
• Where appropriate, screenshots or a short video of the implementation are included below (especially for user-visible or UI changes).

Linked issue: #7565 (ready-to-implement).

Testing

• PROTOC=/opt/homebrew/opt/protobuf@29/bin/protoc cargo test -p warp terminal::find::model
• PROTOC=/opt/homebrew/opt/protobuf@29/bin/protoc cargo test -p warp test_find
• git diff --check
• WARP_SKIP_COMMON_SKILLS_INSTALL=1 PROTOC=/opt/homebrew/opt/protobuf@29/bin/protoc ./script/run --dont-open
• codesign --verify --deep --strict --verbose=2 target/debug/bundle/osx/WarpOss.app
• Manual testing on macOS with large repeated Hans output

Screenshots / Videos

N/A; this is a behavioral/performance fix with no intended visual change beyond capped counts rendering as 1000+.

Agent Mode

• Warp Agent Mode - This PR was created via Warp's AI Agent Mode

CHANGELOG-BUG-FIX: Fixed terminal find hangs caused by eagerly rendering and counting very large result sets.

[cla-bot]

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have the users @hansemannn on file. In order for us to review and merge your code, each contributor must visit https://cla.warp.dev to read and agree to our CLA. Once you have done so, please comment @cla-bot check to trigger another check.

[oz-for-oss]

@hansemannn

This PR is not linked to an issue that is marked with ready-to-implement.

Issue-state enforcement details:

• Associated same-repo issues checked: none

• Required readiness label: ready-to-implement

To continue, link this PR to a same-repo issue such as Closes #123 in the PR description, and make sure that issue has ready-to-implement.

Powered by Oz

[oz-for-oss]

@hansemannn

This PR is not linked to an issue that is marked with ready-to-implement.

Issue-state enforcement details:

• Associated same-repo issues checked: none

• Required readiness label: ready-to-implement

To continue, link this PR to a same-repo issue such as Closes #123 in the PR description, and make sure that issue has ready-to-implement.

Powered by Oz

[hansemannn]

@cla-bot check

[cla-bot]

The cla-bot has been summoned, and re-checked this pull request!

[hansemannn]

/oz-review

[oz-for-oss]

@hansemannn

I'm re-reviewing this pull request in response to a review request.

You can view the conversation on Warp.

I reviewed this pull request and requested human review from: @warpdotdev/oss-maintainers.

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

Oz no longer requests changes for this pull request after the latest automated review.

[oz-for-oss]

Overview

This PR debounces non-empty find-bar edits, keeps empty queries immediate, and flushes pending updates before navigation, close, and option toggles. The added regression test covers rapid typed edits coalescing into one emitted update.

Concerns

No blocking correctness or security concerns found in the changed lines.

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

[vorporeal]

we're working on a full redesign of the find implementation, which makes it async and will be a comprehensive fix for performance issues with find.

i'm a little hesitant to merge in additional changes here right now because:

1. they will hopefully not be relevant for long
2. worried about painful merge conflicts with the open PR to add the basic asynchronous find implementation.

thoughts?

[hansemannn]

Hi @vorporeal, good to hear from you! Usually I would say "go for the bigger goal" and wait for the larger fix, but this one really happens since forever and nearly every day now - especially as agent sessions become larger and more verbose. It even crashed two times today alone, causing the TUI flow to be interruped and forcing me to use the Terminal.app on macOS instead.

Therefore, if you could accept this one as a go-to solution until the bigger change lands, heavy user (like myself) would really appreciate it a lot!

[vorporeal]

whoa, it's concerning that there would be crashes in the find flow as a result of the performance issues. like, actually crash to desktop?

[hansemannn]

Yes, it hard-crashes / needs to be force-quit after 30+ minutes (ANR -> Crash). I've also reported the issue via Apple's crash reporting a few times, but I assume that channel (via App Store Connect) cannot be properly monitored at your scale 😊. So yeah, it's the only issue I have with Warp, but a quite critical one affecting productivity.

And to be honest, it's not too suprising: If I type "c" in a field and there are 3000+ matches immediately, Warp tries to highlight them in the TUI before even getting the chance to type "command" till the end 😅

EDIT: Attached one of the crashes here!

[vorporeal]

hmm, hard to tell what's going on from that report. if you've got crash reporting enabled in the app, and you're willing to share your email address with me (can email me at david at warp dot dev), i can look up our crash reports and see if i can find what's going on for you.

in terms of moving this PR forward, we have a general policy for PRs that the author does some amount of manual verification that the proposed change actually addresses the underlying issue. you should be able to install the metal toolchain (there's a command at the end of the error you provided) and get through the rest of the compilation process.

[hansemannn]

Hi @vorporeal! The initial Metal error was from early testing - Codex ingested it into the stack summary. All tooling is installed properly! Since the initial testing, I've compared it more to how others solve this issue and it seems like the more solid solution is the following:

• Don't select all matches immediately, only the last in the frame
• Show a total count of matches and allow to navigate between

This is also how the built-in Terminal.app solves it and I find it most elegantly for what we need here. A screenshot of the actual compiled app is attached here:

[vorporeal]

hey @hansemannn! @vkodithala has taken up the reins on getting an asynchronous find implementation - an initial implementation (with some bugs that we still need to quash) has been merged into the codebase (under feature async_find). we're aiming to have an opt-in "experimental" version available on the preview+stable builds next week.

in terms of the behavior in your last message around only highlighting the active match - is that something you'd want even with a fast/performant find implementation? i.e.: would you propose it as a setting (e.g.: "Highlight all find matches", defaulted to on, to match the existing behavior)?

[hansemannn]

Hi there! A "show all" does not really make sense and I don't see a real value in it. If you can get it done in a performant way, it's interesting, but it will be hard to do on the main thread without lagging, as you're limited to the frontend tools to render it.

[vorporeal]

i'm trying to tease apart exactly what you're proposing. you want to only display the currently highlighted match, instead of all matches, with the currently-highlighted one in a different color?

i understand the utility of that when you're searching for a needle in a haystack that is the needle repeated over and over, but i'm not sure that's a particularly common behavior, in practice. i think most of the time, people are searching for something relatively uncommon, and it's valuable to see all of the matches at the same time.

i'm not against changing the behavior, but i want to make sure what we land on is optimized for the typical usage patterns.

---

The find bar still reports the total immediately for normal result sets. For very large result sets, the synchronous count is capped at 1000 and displayed as 1000+, avoiding the same main-thread scan that caused hangs with repeated matches such as printf 'Hans%.0s' {1..1000000}.

this helps when there are many matches in a small range (e.g.: your example), but if the matches are sparse, and the total haystack being searched over is large (many long blocks), the cap on the number of non-lazy results doesn't help improve overall performance, right?. if there are two results for my query, and one is at the bottom of the blocklist, and the other is 20M lines away, a synchronous search is still going to spend a very long time finding the second result.

[hansemannn]

You are very right - the general search algorithm needs to become more background thread focused. To be honest, I don't know how Terminal.app or possibly others solve this right now, but there must be a more performant way - maybe even a native system API? In any case, as mentioned before, I am happy to use a different approach and close this one, as long as the basic issues of AnR'd / crashing Warp instances are fixed.