Editor Find/Replace should have better history handling

[brad-provident]

It is not obvious that you can use the arrow keys on the Editor's Find/Replace "Find" field to populate it with previous things you searched for from there (the placeholder hint only shows when there is no text in the box already, which on my Mac is almost never). And it isn't always consistent between tabs which text is in that history (if the system-wide "find" term on the Mac gets added more than once to that field, it is only done so in the first tab, it seems). And there is never much history there, as it gets cleared frequently on its own (during restarts of the app, and maybe other times too). Which is extremely annoying when you want to go back to a complicated regular expression search you had before.

So, I'd recommend the following improvements:

• Write the "find" history to disk, and update it whenever the field changes and a new search is performed .
• Use that history whenever opening a new window or tab, or switching between tabs
• When the user focuses the "find" field, show a scrollable menu underneath it of all the previous find terms, up to some maximum. User Settings determine what the maximum is, and whether or not the user actually wants this menu to appear every time.
• Once the user starts typing anything in that field with a keyboard, turn the menu into an auto-complete menu (i.e. filter it based on what text is in the field).
• Add a clock icon button to manually trigger the full list menu.
• If the "find" terms selected from the menu also had one or more "replace" texts used with it, present those as choices when the user focuses the "replace" field.
• Also have a clock icon button to manually trigger the full list menu or "replace" terms used.

[vezaynk]

Once the user starts typing anything in that field with a keyboard, turn the menu into an auto-complete menu (i.e. filter it based on what text is in the field).

Auto-complete on search fields a bad idea for anyone searching for similar terms.

If the "find" terms selected from the menu also had one or more "replace" texts used with it, present those as choices when the user focuses the "replace" field.

This sounds difficult to implement and a footgun to use

The only change I would make here is to allow users to have a dropdown of the search history instead of requiring them to spam the up key.

[brad-provident]

Even just having the dropdown menu, and having it retain its contents between sessions and be consistent in all tabs and windows would be a marvelous improvement.

I do want a menu for replace terms too though, as that can be complex Regular Expression replacement text. Even if it is just a simple list of all the replacements previously entered there.

Oh, and don't do what BBEdit did, by alphabetizing the list. That was horrible. It should be sorted by recency, with most recent at the top.

[IllusionMH]

Looks like duplicate of #23099 with long description.
The only thing that may be not mentioned there and should be added as a comment if wasn't already - filter on type.

[brad-provident]

Also, the idea that the "find" history should not disappear all the time (like whenever I need to restart the app or the computer) is a pretty important aspect of this ticket. And that the Mac's shared "find" terms should affect all tabs and windows equally, in terms of how it adds to the history.

Really, the in-document "find" feature in VS Code is ripe for several improvements, and has been for some time, as these issues keep coming up and getting reported repeatedly.

[IllusionMH]

AFAIK search history is preserved for workspace and it's definitely not lost just on app restart.

But if you have 5 different projects/workspaces they would have separate histories tied to them.

If history is lost on app restart - you should create separate ticket focused on that problem.

[brad-provident]

I think you might be confusing search history and find history, as they seem to be different. I am talking about the history of the find field for in-document finding (command-f or control-f), not the separate tab for multi-file searches.

But also, I don't want 5 different histories for 5 different workspaces. It should be global within VS Code, IMO.

[brad-provident]

Also, having so many different histories is too complicated and hard to navigate. Mac has a global "find" term that is shared between apps, and that is very simple and convenient. VS Code goes the other way, with separate terms (aside from Mac's global "find" term) and histories between different projects, tabs, find vs search feature, etc. The convenience and simplicity of being able to share find terms and histories cannot be overstated.

[vscodenpa]

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[rjendoubi]

Hey @IllusionMH, I created a separate ticket for the lost history as #170591; it's been marked as a feature req, but if I understood you correctly, this is not expected behaviour and should be addressed as a bug. Could you weigh in on that one please?

[vscodenpa]

This feature request has not yet received the 20 community upvotes it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[vscodenpa]

🙁 In the last 60 days, this feature request has received less than 20 community upvotes and we closed it. Still a big Thank You to you for taking the time to create this issue! To learn more about how we handle feature requests, please see our documentation.

Happy Coding!