Add search_on_input setting to Project Search

[holoflash]

I was really missing the ability to instantly see search results while typing in the Project Search and decided to try and implement it.
As this may not be a feature that everyone wants, I made it toggle-able via the settings (or the settings.json)

Settings

Set to false by default

settings.json

Set to false by default

Video demo:

search_on_input_demo.mov

• Search input is debounced with 250ms in this mode (cool?)

The desire for this feature has been expressed here too: #30843

Release Notes:

• Added a setting that allows to show search results instantly in Project Search
• Added tests

[cla-bot]

We require contributors to sign our Contributor License Agreement, and we don't have @holoflash on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'.

[cla-bot]

We require contributors to sign our Contributor License Agreement, and we don't have @holoflash on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'.

[holoflash]

@cla-bot check

[cla-bot]

We require contributors to sign our Contributor License Agreement, and we don't have @holoflash on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'.

[cla-bot]

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

[cla-bot]

We require contributors to sign our Contributor License Agreement, and we don't have @holoflash on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'.

[cla-bot]

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

[holoflash]

@cla-bot check

[cla-bot]

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

[P1n3appl3]

I've been playing with this change for a little bit and I think we want to land it. Thanks for the feature and I appreciate the added test! I've got a couple of thoughts, but not all of these need to be resolved to merge the feature.

• It's hard to pick a debounce time that works for everyone, but I don't think it warrants making a setting. If anything 250ms feels a bit high for me. I wonder if it'd be possible to scale it based on worktree size (so in tiny projects you get instant results, and in huge ones you don't get thrashing...) or if that's overcomplicating things.
• There's some visual jitter when the matches refresh. I get that we want to stream matches in instead of waiting for them all to show up, but I think it might be better UX if we don't always show an empty list for at least a frame. Despite the ordering being stable, I keep losing track of a match when it's only barely moving on the screen just because it flashes.
  • I've tried opening this with larger projects such as the rust compiler, and there it's pretty annoying when you see some matches, type a few more characters, and all the existing matches disappear for a few seconds and you just see an empty pane with "searching". I'm increasingly convinced that for the updates we'd want to keep showing the previous results until we have at least one new result or we finish the search and determine there aren't any matches.
• This doesn't matter too much since the setting is opt in, but I worry that we'd really want to do some performance optimizations to avoid fully re-searching everything when the query changes. Caching logic might be too complicated to be worth it, but @osiewicz mentioned that it might be a good idea to keep track of all the files where no matches were returned. That way for the common case of adding a few characters to the query we could in theory avoid re-searching all those files. Of course in the general case (especially when regex matches get involved) this doesn't hold up, but it seems like a decent heuristic that covers the most common usage and could potentially be a huge perf win.

[holoflash]

@P1n3appl3
Thanks so much for the review!
I'm looking into some of the things you wrote and here are some thoughts so far:

• Removing the debounce entirely makes the search feel much smoother overall. Big and small projects. I have a local commit ready to be pushed with it removed if you agree.

I made it opt-in because I assume that there's a good reason for the current implementation (hitting the ENTER key), but coming from vscode, I'm used to the results showing instantly, and being able to search right in the file browser.
Could you fill me in on why the current approach was chosen in the first place in ZED? Would help me understand what else needs to be done to make this feature work nicer.

As for the other points. I'm not really sure what the best approach might be. Maybe if something is inputed in the search field, continue the search but ONLY on the results coming from the previous query? (would need to temporarily cache the results?)

• user types: "express" --> get search results for "express"
• user types: "expression" ---> continue search but only on results from "express"
• user types: "expression a" ---> continue search but only on results from "expression"
• user erases some letters: "expressi" ---> continue search but on results from "express"
• user erases more letter:" expre" ---> do a new search because query is broader than initial search.

This might need a little debounce though to not trigger on each letter if typed quickly.
Could be done in reverse as you mentioned by excluding results instead.
Just high level thoughts, I don't know how to go about implementing this as I'm writing.

I'll just push the version without the debounce so you can get a feel for it.
Maybe that alone might make this work without all the extra stuff.

[Be-ing]

I could imagine wanting this enabled sometimes (small projects) but not others (large projects with rust-analyzer regularly stressing my system). I wonder if it might be better to make this toggleable with a button next to the search bar by the filter and case sensitivity buttons instead of buried in the settings. That would also make it more discoverable.

[holoflash]

@Be-ing
I personally would like that too! Just not sure if it's too intrusive of a feature.
But here's what that could look like:

Screen.Recording.2025-11-22.at.10.41.35.mov

I just pushed the above as a suggestion.

[P1n3appl3]

It's worth noting that the "quick search" feature in #44530 implements this functionality. I think it may still be worth doing here, but we should at least use the same logic between the impls.

[holoflash]

It's worth noting that the "quick search" feature in #44530 implements this functionality. I think it may still be worth doing here, but we should at least use the same logic between the impls.

Neat @P1n3appl3
I'll see how that one progresses and if I can use the new quick_search for this instead.
Coincidentally ended up binding ⌥+cmd+q to toggling this feature, so even that part makes sense 🤩