cmd+shift+f doesn't use search query from current local search

[porsager]

Check for existing issues

• [X] Completed

Describe the bug / provide steps to reproduce it

Starting a local search (cmd + f) and entering something to search for, and then going to global search (cmd + f) removes the search query previously entered, instead of keeping it, so that it is easy to "search broader" if needed. I do this many times every day, and it is annoying having to retype the search query every single time.

Environment

Zed: v0.128.1 (Zed Preview) OS: macOS 14.3.1 Memory: 32 GiB Architecture: aarch64

If applicable, add mockups / screenshots to help explain present your vision of the feature

https://github.com/zed-industries/zed/assets/1288405/497b10ed-0cb3-43fb-a20f-065f72e09361

Notice in the uploaded screen capture that "here some" is replaced by "here" when pressing "cmd + shift + f". It seems to insert "Here" instead because that was the most recent "result" while typing "here some". I cannot imagine the expectation here would be anything else than having "here some" still present as the search query.

I can see how it ended up like this by wanting to use the word before the cursor as a prefilled search term, but I think it doesn't make sense for this specific scenario.

If applicable, attach your ~/Library/Logs/Zed/Zed.log file to this issue.

No response

[petros]

That's an interesting use case @porsager 😄. Thanks for sharing it.

I am not entirely sure this is a defect. I might be wrong but it seems more of a proposed new way that would handle the use case you have shared. I am saying that cause the current behavior is something people are expecting when the cursor is on a word and they need to quickly invoke global search for that word.

The use case you are describing is:

1. Local search for xyz
2. Observation: Couldn't find xyz in the local buffer
3. Expectation: Have a way to quickly do the same globally

That might need new functionality rather than changing the currently expected behavior with CMD+Shift+f. Maybe a "Search globally" option right beside the "No matches" text in red? Or something along those lines?

[porsager]

I'm just used to this behaviour from sublime :)

I get the behaviour you're describing makes sense when the cursor is active next to a word in the editor, but I have a very hard time imagining any user wanting the current behaviour I described when the cursor is active in the search input field.

I think the expectation is that the search input field is the same regardless of local / global search, and the fact that content in it changes because the search scope changes is unexpected.

[petros]

I get the behaviour you're describing makes sense when the cursor is active next to a word in the editor, but I have a very hard time imagining any user wanting the current behaviour I described when the cursor is active in the search input field.

I see what you mean. I can't think of a good way for CMD+Shift+f to support both scenarios, while keeping everyone happy. I guess we can let others chime in 😄.

It seems when the focus is in the search bar the first time you type something and there's a match, although the cursor is not blinking anywhere in the buffer, CMD+Shift+f takes the first match. If you return back to the buffer after the global search, you see the cursor is actually blinking at the beginning of the first match.

[porsager]

That's assuming anyone expects the current behaviour, which I would wager isn't the case 😉

Everything actually stays the same but becomes more consistent by having global search be prefilled with what is around the cursor in the active input, instead of specifically the cursor in the editor.

Another thing I discovered while testing this, is that it also doesn't prefill global search with text selected in the terminal. That is also a bit weird.

So my suggestion is - "find in project" (cmd+shift+f) should use the following "prefill" resolution logic.

• First try current selection in focused view (be it in terminal, editor or search input)
• Then try currently focused input
• If single line input, use full line (this is what solves this issue)
• If editor use word at cursor position. (this is the current expected usage)

[Moshyfawn]

I believe the current intended behaviour was to "reuse" the last applied search query in case you switch to global search.