Add quick search modal

[davidbonan]

Summary
Implements a quick search modal for project-wide searching.

Features
This modal allows users to quickly search for files and content within the project. It includes a picker for displaying search results and a preview editor for showing the selected result.

Enregistrement.de.l.ecran.2025-12-10.a.12.04.48.mov

Performances tested on large codebase (monorepo and zed project).

Related issue #8279

Release Notes:

• Added quick search without multibuffer

[zed-industries-bot]

	Messages
📖	This PR includes links to the following GitHub Issues: #8279 If this PR aims to close an issue, please include a Closes #ISSUE line at the top of the PR body.

Generated by 🚫 dangerJS against edfab4a

[gustavotrott]

THANK YOU! Can't wait to use it.

While watching your video, I noticed the typed word wasn't highlighted in the preview window. I suggest to highlight the word too and not only the line!

Also, about Prevent file modification in the preview.. Being able to modify in the preview would be really useful if it's feasible to support.

[davidbonan]

@gustavotrott I have a UX problem with that:
If I modify a file in the modal, the file is modified but not saved and not opened in the main editor. I find it disturbing to have an unsaved modified file that is not open. Any suggestions?

[davidbonan]

Update :

• Allow modifications directly from the preview, when modifying in the preview, the file opens silently in the main editor.
• Quick Search panel has a fixed size
• Results counter in the header ("42 results in 8 files" or "200+ results (limited)")
• Add search options: Case sensitive, Whole word, Regex, Include ignored
• Collapse/expand files (click on the header)
• Secondary actions: Cmd+Enter to open in a split
• When text is selected in the editor, pre-populate the search field with this text when opening the quick search mode.
• Highlight the word in the preview
• Improve UI (square borders, header and footer)
• Improve UX (upon clicking the mouse, we open the preview instead of opening the file directly in the editor and closing the modal)

[baldwindavid]

Nice. This is the sort of experience I'd like to see for ALL modals as it's very similar to Helix. I wanted to do something like this for #43961 , but already a stretch to get a new modal. If you get any traction on this, I'd love to build this sort of thing into my PR.

[maxbrunsfeld]

Testing this out now.

@davidbonan First impression - this is a good feature, it seems to be a very popular request. Your implementation fits into the codebase pretty cleanly and seems high quality. Thank you for doing this!

My only concerns are about UX inconsistency and elegance. Are there any opportunities to make this fit in better with the rest of Zed. I'm going to spend some time this morning exploring this.

@baldwindavid I took a look at your PR too. It seems like, once we land this, you should restructure your PR to make use of some of the same code for previewing buffers, and make the modals look consistent.

[davidbonan]

@maxbrunsfeld Thanks for the feedback.

Could you provide one or two concrete examples of what you’re looking for in terms of UX consistency or elegance ?
In particular, if there are specific existing screens, modals, or flows I should align with, that would be very helpful in guiding the changes.

[maxbrunsfeld]

Just streaming out feedback as I test:

• Performance - Testing in chromium, the latency is much worse than our current project search, because we wait to get all the matches before updating the list, instead of streaming in the results. I think we need to stream the results in to the list, so that it feels fast in large repos.
• UI - Usually in Zed, whenever we show code, it is syntax-highlighted. Even LSP completions get highlighted. I think there is an opportunity to syntax-highlight the lines in the list: we already open every buffer as part of the Project::search API. Right now, the quick search view is immediately dropping all of the open buffers after extracting the matched lines. But instead, we could keep them open until parsing completes, so that when it does, we can update the matches for that buffer to show the syntax-highlighted lines.
• Performance - As a continuation of this thought ☝️ , should we keep all of the buffers open once we find results in them, rather than dropping any of them? It would make it very fast to update the preview. I noticed that right now, there is a delay before the preview updates.

[maxbrunsfeld]

I pushed up one small change to prevent the result count header from briefly disappearing (causing vertical shifts) when searching.

Can you address the latency issue, streaming in the results? Do you have thoughts on how that should work, or if there are any issues with adding that?

[P1n3appl3]

@yara-blue this overlaps pretty heavily with the telescope design stuff we were talking to @danilo-leal and @mattermill about.

[baldwindavid]

Just off the top of my head some recent PRs, discussions, and issues are related:

• Telescope-style search box #8279 (comment) - A video of a very similar feature to this one that was not opened as a PR afaik.
• Easy Telescope-style file finder in Zed #22581 - Discussion I added earlier this year about leveraging the television TUI for live search of files and content which is similar to this.
• Traditional "Find All References" etc. views #5117 - Issue that @maxbrunsfeld just commented on noting that this sort of UI could be used for find all references.
• Add Helix jump list navigation #44661 - Jump list navigation similar to helix
• Add file explorer modal #43961 - My PR for a netrw / yazi / ranger type file explorer. This attempts to add the sort of functionality from this yazi workaround (Netrw-ish File Explorer Today #9067) with the existing Zed modal paradigm.

I think that all of these are driving towards a request of an experience similar to the one in this quick search PR. This is basically how everything is presented in Helix. Not that we need to copy Helix, but I do think it would be beneficial to take a holistic approach to this. This PR seems like a great one to polish up to set the tone for future pickers.

[davidbonan]

@maxbrunsfeld
Updates:

• Add syntax highlighting to the preview.
• Caches buffers to improve performance.
• UI : Add rounded border + Improve header to match with ProjectSearch view

[maxbrunsfeld]

Are you streaming the results in now?

[davidbonan]

Are you streaming the results in now?

Yes in line 1558 you can see the stream process

[maxbrunsfeld]

Thanks for explaining; I’ll manually test and review again

[maxbrunsfeld]

@davidbonan The new UI looks great, streaming is looking good.

I hit a problem when using it in the chromium repo, typing in the search bar seemed to freeze the editor. I think there are already some performance problems with regular project search, so I'm trying to figure out if there's anything we need to do in this PR to make sure we handle long-running searches properly.

Could you test that scenario when you get a chance? Searching in a large repo like WebKit, Chromium or Linux

[justsomelegs]

hey @davidbonan nice work!, it might be worth us working together on this tbh, i've been working on basically the same things but with a focus on modular sources #44942.

if not i understand but just a thought?

[davidbonan]

I have landed the project search cancellation changes in #45406 (that @maxbrunsfeld paved the way for in #45300); I think we're good to remove project search changes from the scope of this PR now.

@osiewicz Wow, the cancellation mechanism greatly improves the speed of searching in “search on input” mode.
Thx!

[maxbrunsfeld]

Manually testing this one more time, now that #45406 has landed.

[maxbrunsfeld]

@davidbonan The UI is looking really good; I'm liking the larger size.

It looks like we are starting and stopping language servers as we page through the different preview buffers. I think that there is some way of opening a buffer without starting language servers. We do that for instance when a buffer only appears as an excerpt in a multi-buffer. I think we should do that here.

One other question - what do you think should happen when you click with the mouse on a certain spot in the preview buffer? Right now it puts your cursor there, and transfers focus to the preview buffer, and you can actually edit. If you edit, it opens that buffer in a tab below the modal, but the modal stays open. I think that's a bit odd. Maybe we should make the buffer read-only in this view. I also wonder if we should even keep the modal open if you click to the preview buffer. Maybe at that moment, we should just immediately open the buffer in a tab, and put the cursor at the location where you clicked. Thoughts?

[osiewicz]

@maxbrunsfeld

It looks like we are starting and stopping language servers as we page through the different preview buffers. I think that there is some way of opening a buffer without starting language servers. We do that for instance when a buffer only appears as an excerpt in a multi-buffer. I think we should do that here.

Yeah, classic multi-buffers are lazy with regards to spawning language servers. The main API for it is Editor::register_buffer which is called on selection changes and such. If we're spawning language servers in preview buffers, then most likely that function is getting called from one of it's call-sites.

[gustavotrott]

Maybe we should make the buffer read-only in this view. I also wonder if we should even keep the modal open if you click to the preview buffer. Maybe at that moment, we should just immediately open the buffer in a tab, and put the cursor at the location where you clicked. Thoughts?

I think that would actually be a shame.

Being able to edit the file directly inside the modal is extremely useful. I rely on this all the time in JetBrains editors. For example, when I need to make the same change across several different files, I just use quick search and apply the edits right there, jumping between files and adjusting each one without breaking the flow.

Automatically closing the modal on click would also feel quite awkward and not very practical. Sometimes I just want to select some text in the preview to copy a snippet of code. With that behavior, it would immediately open the file in a tab, which is not what I want in that moment. I would much rather depend on a double click or pressing Enter to explicitly open the file.

I am not sure what the best solution is to allow editing inside the Quick Search modal, but the current behavior in Zed where multiple files open stacked and are directly editable works really well for me. Having that same capability inside the Quick Search modal would be even better. If it is possible to reuse an approach similar to what already exists for editing inside Project Search, that would be great. Otherwise, not allowing edits there would feel like a clear downgrade.

[maxbrunsfeld]

We can allow editing, but then we shouldn’t also open the file in the workspace below the modal. And I guess we would need to auto-save the buffer when you change the search query after editing in there, because otherwise the buffer might be dropped without saving your changes.

[maxbrunsfeld]

Thanks for the feedback on the feature

[marcocondrache]

Just my two cents: If the quick search modal lets you edit, how is that really different from global search with multi-buffer? Feels like the same thing, just shown differently. I always thought quick search was meant for quickly finding and inspecting something, not editing.

[sf0rman]

I really like this, but instead of a popup window, it would be nice if the found files show on the left (where project_panel, git_panel etc go) and the content for each shown in the main screen.

[gustavotrott]

Just my two cents: If the quick search modal lets you edit, how is that really different from global search with multi-buffer? Feels like the same thing, just shown differently. I always thought quick search was meant for quickly finding and inspecting something, not editing.

Read the issue #8279 and you will understand the difference.

[ryanwinchester]

Is there a keyboard shortcut to open all the results in multibuffer?

[feeiyu]

I have a small suggestion after using this feature:
When opening a file from Quick Search and then opening Quick Search again, would it be possible to restore the previous search state (query and results)?

I think this could make repeated navigation a bit smoother.

[mattermill]

This is looking really good so far! I made some changes to respect OpenExcerpts shortcuts in the quick search preview.

I pushed them to davidbonan-quick-search-open-excerpts if you could review, or allow edits from maintainers.

cc @maxbrunsfeld

[davidbonan]

I pushed them to davidbonan-quick-search-open-excerpts if you could review, or allow edits from maintainers.

@mattermill Normally it’s already activated

@maxbrunsfeld Before applying the changes or revert changes requested in the comments, I would like to have confirmation from the Zed team on what is wanted