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.