Move "find" widget to panel, make consistent with search in files, preserve search query

[adamreisnz]

Coming from Atom, I cannot come to terms with how the "find" widget appears in the top-right of my screen, barely visible, with a weird dropdown to toggle replace option, and then the search in files has a completely different UX and is displayed at the bottom in a panel (or sidebar).

The find & replace, both in current file and globally, is one of the things in Atom that was done really well. You often have to switch from finding in a file to finding across all files, and the current experience in VS Code is simply subpar and inefficient.

I've searched for extensions that would move the find widget to a panel for consistency but to no avail.

Can you please consider improving the find UX and move the widget down to the panel for a consistent experience, along with other improvements like:

• Shared search query between find in file & search in files
• Consistent layout
• Clearer active state for search options
• Buttons to toggle searches with mouse rather than keyboard only

Compare the two below and judge for yourselves which has the better UX:

Atom

Search in files

• Large search area in panel
• Large buttons for Find all and Replace all
• Replace option always visible and readily available
• Large buttons for search options
• Clear to see which of the options are active by distinct blue highlight colour

Find in file

• Consistent UX compared to search in files, all the options in the same place.
• Big buttons for Find, Find All, Replace, Replace All,
• Replace option always visible and readily available.
• When switching between find in file and search files, the search and replace queries are preserved.

VSCode

Search in files

• No action buttons to click for searching (only keyboard activated)
• Search options are small, embedded in the search box, and hard to see if active or not with a thin blue box around them. Not enough contrast.
• Hard to access replace option, always hidden behind the dropdown, despite there being plenty of space beneath the panel
• Unclear how to actually make replacements in file. I literally struggled to figure out how to replace in files the first time I tried to do it.
• We won't talk about how the search results appear in the same panel as that has been covered by many other issues.

Find in file

• Located at the opposite end of the screen, forcing you to switch context from one end of the screen to the other. Very hard to visually see what you're searching as it's hovering over the code in a tiny box.
• Doesn't share search query with search in files, so have to retype it in/rebuild the regex when switching context
• Same problem with tiny search options, poorly distinguishable and hard to see if active
• Replace also inaccessible by default and always have to toggle to open it up

[vscodebot]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• Option for unified Search / Replace Bar (#72725)

[roblourens]

This isn't the first time these comments have come up, although I still mostly prefer the vscode way of doing things 😁

[adamreisnz]

Another use case where the current behaviour is annoying is the following:

1. Perform a search in files for foo
2. Open file where this search occurs
3. Press CMD+D to add selection to next find match or CMD+G to navigate search results

Expected: foo instances are added to your selection and you can navigate the found matches

Actual: the search in file shows up and you have to retype foo if you want to navigate the matches, or worse, a previous search term is highlighted instead.

Combining the two search options in one panel, or at the very least having them share the current search term, will resolve this.

[adamreisnz]

What compounds it even further, is that I noticed the find widget doesn't even share the search query between editors.

That means if you are doing the above in multiple files, you'll have to re-type the search term for every single file.

[adamreisnz]

I found that (at least on OS X) the latter problem can be overcome by using the options:

"editor.find.globalFindClipboard": true,
"search.globalFindClipboard": true,

[ArturoDent]

On your issue of hard to see if active options, I agree. You can modify that with these colorCustomizations:

      "inputOption.activeBorder": "#666",                   // use your colors
      "inputOption.activeBackground": "#db1717",    // especially this one
      "inputOption.activeForeground": "#fff",

[tukusejssirs]

I am coming from Sublime Text and would like to see this implemented too. Moreover, I think that all those find/replace settings (while search the current/active file) are somewhat badly designed/aligned. I think that ST has designed the find/replace panel better by moving all find/replace settings (regex searching, case-sensitivity, whole word matching, search wrapping, searching in selection, case preservation and highlighting of matches) on the of the of the find/replace text boxes.

[shellscape]

I'm coming from Atom as well - as the teams at Github have completely abandoned the architecture behind APM prematurely. I digress. At any rate, the find widget is unbearably "Microsofty" or "Chromey." The way that Atom handled find and replace in a single dialog in the same, consistent place, is vastly superior for DX and UX.

Count my vote as one to allow this dialog to live at the bottom in the panel with the rest of its siblings.

Additionally, VS Code has bizarre bugs with alignment and phantom space in the editor with the widget at the top as can be seen in the attached video.

Nov-09-2022.21-13-59.mp4

[roblourens]

Not a bug- this is so you can avoid the find widget overlapping editor text

[shellscape]

@roblourens if that's a feature, it should have a CTA explaining as much. That's a completely foreign concept coming from other editors that more sensibly put the find/replace dialog beneath the editor. Coming from Atom, this was completely jarring and was driving me bonkers trying to figure out what wasn't working right. I even tried reinstalling. Several long-time VS Code users in my peer groups confirmed they were seeing the same thing and stated that they thought it was just a bug that would eventually get fixed - people who've been using VS Code for years didn't even know that was a feature. It seems a lot of UX decisions have been made as if they're expected, when in fact they're not at all.

[vscodenpa]

We closed this issue because we don't plan to address it in the foreseeable future. If you disagree and feel that this issue is crucial: we are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding, and happy coding!