text_finder: Seed last query and filters to make quick edits easier - #59849
Conversation
…arch (zed-industries#59779) ## Summary When opening the text finder (`text_finder::Toggle`), pre-populate its query the same way project search already seeds itself. Previously `seed_query` only asked the active editor for the word under the cursor, so opening the text finder from a project search tab or a focused buffer search bar started empty. `seed_query` now tries these sources in priority order: 1. **Active project search** — its current query (`ProjectSearchView::search_query_text`). 2. **Focused buffer search bar** — its query, reusing project search's existing `buffer_search_query` helper (promoted from private to `pub(crate)` so there's one source of truth rather than a copy). 3. **Word under the cursor** — the existing `query_suggestion` fallback, still honoring the `seed_search_query_from_cursor` setting. This mirrors how project search is fed from the buffer search bar (`existing_or_new_search`), keeping the seeding behavior consistent across the three search surfaces. ## Testing - Manual: open project search with a query → toggle text finder → query carries over; cmd+f with a query focused → toggle text finder → query carries over; otherwise the word under the cursor seeds it as before. Release Notes: - Improved text finder to pre-fill its query from the active project search or buffer search --------- Co-authored-by: ozacod <ozacod@users.noreply.github.com> Co-authored-by: Yara 🏳️⚧️ <git@yara.blue>
cla-bot
Bot
added
the
cla-signed
|
Good idea! Taking it one step further I've added #59895, though that does not exclude this.
mhmmm this seems fine, feels off though :) I'll see if I can think of anything. |
Now it uses workspace table instead of using shared database. It is already existing pattern for bookmarks which is also persistent after project is reopened. |
5b37baa to
4d6c924
Compare
6368e8c to
1794879
Compare
ozacod
changed the title
| /// item in priority order, mirroring how project search seeds itself: an | ||
| /// active project search's query, then a focused buffer search bar's query, | ||
| /// then the word under the cursor (honoring `seed_search_query_from_cursor`). | ||
| /// The query to pre-populate the text finder with, sourced in priority order: |
There was a problem hiding this comment.
rather a long doc comment (the function itself is not hard to read). Might be replaced with something like: "Guess the query the user probably wants for pre-populating the search input"
yara-blue
added
the
area:pickers
|
I've been thinking about this, it might be better to pivot this to a query history system and look into restoring the entire picker. That restoring would not work through persistence, we would just not "close" the picker fully. We'd hide it. Would that cover your use case? |
|
After this PR is merged, I was planning to add a history system by keeping the latest 10–20 queries in the database, like we did for the last one, then seeding history[0] into the search query. The user would then be able to go through the history with option+arrow keys. It would be a relatively complex PR, since not everything searched should be fed to history (the live-search problem). Debouncing isn't a good idea either, since the time interval would have to be determined heuristically; instead we'd Restore (#59825) could also be defined as a separate action with its own keybinding, so both could be active at the same time. It wouldn't be fully redundant, since restore could also bring back scroll and selection state, not just the query. But the two would still overlap on the query part, so having both might feel like two similar ways to do the same thing. I'd leave that decision to the team. I'm open to closing this PR depending on the design decision. Restore also touches the dismiss path: depending on whether we retain the picker (and decide when to actually drop it) or fully close it and rebuild from a saved snapshot, so it's a bigger change than the history part. Personally, I'd lean toward making the preview editable instead that removes the round-trip entirely, since you could fix the typo in place without ever reopening. It's an alternative to the restore flow rather than to query history, though. I saw it was already raised in #59825 and the team leaned toward the restorable picker over it, so I assume it's off the table, just noting my preference. |
|
I gotta run and get started on dinner but before I go I wanted to share the prototype we build for restoring the last picker: #59912 I'll try and get that in the right shape tomorrow.
Good point! Still would be amazing to have, especially for regexes.
I'd love you're input on this after landing the restorable picker. Similarly I'd want to try it for a bit to see how it feels. The same is true for this PR. This might still be useful even with the restorable picker. I gotta think and confer with some collegues about that. As a stepping stone to a full history it's already great. Could always put it behind an arrow up press. Anyway I hope to get back to this tomorrow, if I don't feel free to ping me! |
smitbarmase
added
area:search
|
Hi @yara-blue, |
Then let's get this merged 👍 |
|
Great work. I think it might be a good idea to have the last query be configurable. I would like to disable it because my workflow is to always search for the word that is under the cursor. |
Pr's are welcome! Zed used to have a setting for the size of the file finder, I think we can have a pickers setting category. Might be useful when the LSP pickers land too. (Could have something like use pickers over multibuffers for lsp requests). |
…ed-industries#59849) ## Summary It is incremental step to solve issue zed-industries#59825. This PR addresses the need for facilitating quick edits for matches obtained by ‘text_finder’. This makes the text finder remember the last query, so you can jump to a match, make a quick edit, and reopen the finder to the same results instead of typing the same query again. ## Problem A common flow is, open the text editor, then jump to first match, edit that file, then reopen the finder to continue for next matches. But on the reopen, the query was seeded from under the cursor. And after editing, the cursor is usually sitting on an unrelated word, and previous search was lost. The root cause is priority, the word under the cursor was seeding the query. ## Solution Reorder query seeding so last query outranks the cursor word, then cursor word can be dropped entirely, since last query is prioritized over the word under cursor, the last query always wins, so checking the cursor word afterwards is dead code. And JetBrains makes the same choice, entirely ignores word on the cursor for seeding query. Explicit selection still outranks the last query, since selecting text is usually a deliberate choice. ### Before 1- Active project search query (if any) 2- Active buffer search query (if any) 3- Selected text or word under the cursor 4- Empty ### After 1- Active project search query (if any) 2- Active buffer search query (if any) 3- Selected text 4- Last query (of this project) 5- Empty With updated order, this friction disappears (the same order is also observed in JetBrains). To make the last query persistent, it is stored per project in the database along with the active filters (case sensitive, whole word, regex), so they also survive reopening the project. ## Testing - Manually verified the seed priority order between the options. - Verified the last query is seeded when project is reopened. - Verified filters are restored regardless of this query order. Release Notes: - Improved the text finder to seed the last query and filters to make quick edits easier. --------- Co-authored-by: ozacod <ozacod@users.noreply.github.com> Co-authored-by: Yara 🏳️⚧️ <git@yara.blue>
4 participants
Summary
It is incremental step to solve issue #59825.
This PR addresses the need for facilitating quick edits for matches obtained by ‘text_finder’. This makes the text finder remember the last query, so you can jump to a match, make a quick edit, and reopen the finder to the same results instead of typing the same query again.
Problem
A common flow is, open the text editor, then jump to first match, edit that file, then reopen the finder to continue for next matches. But on the reopen, the query was seeded from under the cursor. And after editing, the cursor is usually sitting on an unrelated word, and previous search was lost. The root cause is priority, the word under the cursor was seeding the query.
Solution
Reorder query seeding so last query outranks the cursor word, then cursor word can be dropped entirely, since last query is prioritized over the word under cursor, the last query always wins, so checking the cursor word afterwards is dead code. And JetBrains makes the same choice, entirely ignores word on the cursor for seeding query. Explicit selection still outranks the last query, since selecting text is usually a deliberate choice.
Before
1- Active project search query (if any)
2- Active buffer search query (if any)
3- Selected text or word under the cursor
4- Empty
After
1- Active project search query (if any)
2- Active buffer search query (if any)
3- Selected text
4- Last query (of this project)
5- Empty
With updated order, this friction disappears (the same order is also observed in JetBrains). To make the last query persistent, it is stored per project in the database along with the active filters (case sensitive, whole word, regex), so they also survive reopening the project.
Testing
Release Notes: