Modernizing Find in Files

Dante Gagne

Dante

Find in Files is one of the most commonly used features in Visual Studio. It’s also a feature that gets a substantial amount of feedback, and due to the age of the code, has been very costly to improve. Earlier this year, we decided to reimplement the feature from the ground up in order to realize significant performance and usability improvements.

We’ve released the new find in files experience in Visual Studio 2019 version 16.5 Preview 1 and we’re looking for feedback from the community. We expect this experience to be the one our developers will use and love in the future, so we want to make sure we’ve prioritized the right features. We still have more improvements coming that we’re not quite ready to talk about yet, but before we deprecate the old experience, we want to make sure the new version is meeting the needs of our users.

A screen capture of the new Find in Files dialog.

The new experience is available by searching for “Find in Files” or “Replace in Files” in Visual Studio search (Ctrl+Q by default). You can also get to these commands with Ctrl+Shift+F and Ctrl+Shift+H respectively. The new experience is pictured above and should be easily recognized by the more modern look and consistent color theming.

If you’re not seeing the new version, you can search for “Preview Features” in Visual Studio search (Again, Ctrl+Q by default). On that page, make sure “Use previous Find in Files” is unchecked. Conversely, if you’re having problems with the new experience, you can toggle this option to enable the old one. If you do find that you need the old Find in Files experience, we’d love to hear why. Please feel free to supply any feedback you might have over in Developer Community.

Performance

We took the previous implementation of Find in Files and reimplemented it completely in managed C#. This allows us to avoid unnecessary interop calls and gives us much more room for improving the experience. The memory consumption is smaller, and our performance is much faster.

In our internal testing on directories containing 100k+ files, we saw searches that took over 4 minutes with the old implementation be done in 26 seconds. The biggest gains are in searches that use regular expressions, but searches without regular expressions generally cut the search time in half.

Specifying Paths

Using the new experience should feel comfortable for most folks since we’ve gone with an experience that matches many other common find experiences. There are a few nuances that are worth calling out.

A screen capture of the Find in Files dialog that is cropped to only show the Look in and File types fields along with the options to include miscellaneous and external items.

The “Look in” box has a new option, “Current Directory”, which will search the folder that contains the currently open document. When searching a solution, there are checkboxes to include miscellaneous files (files that you’ve opened but aren’t part of the solution) as well as external items (files like “windows.h” that you might reference but aren’t part of the solution).

The three dots button next to the “Look in” box work like any other browse option to specify a directory to look in, but if you’ve already specified a directory, this button will append the new directory instead of replacing. For instance, if your “Look in” value was “.\Code”, you could click the three buttons and navigate to a folder named “Shared Code”. The “Look in” would now show “.\Code;.\Shared Code” and when the Find command is executed, it will search both of those folders.

The File types folder now also can exclude files. Any path or file type prefixed with the “!” character will be excluded from the search. For instance, you can add “!*\node_modules\*” to the file types list to exclude any files in a node_modules folder.

Multiple Searches

One of the more frequent requests we’ve gotten is the ability to keep the results from one search while doing other searches. This makes it easy to compare results and see them side-by-side. This feature has been in Visual Studio for a while, and the new experience still supports it.

In the screenshot above, the Keep Results button has been enabled. Now, when a new search is executed, the results will be shown in a new tab. The screenshot above shows three searches that have already completed. Currently, this feature supports up to five searches. If you’ve already got five search results showing, the next search will reuse the oldest search result tab.

The Keep Results button is available for Find in Files as well as the Find All References feature.

Regular Expression Builder

A screen capture of the Find in Files dialog with a regular expression being used.

With Visual Studio 2019 version 16.5 preview 2, the Regular Expression builder will be available. The “Use regular expressions” checkbox will enable you to specify a regular expression as a pattern for a match. Checking this box with Visual Studio 2019 version 16.5 preview 2 (or later) will also bring up the Regular Expression builder, which is useful for creating regular expressions. Regular expressions can allow searches for strings that span multiple lines. For instance, the expression “.*Hello.*\r\n.*World.*” will match any occurrence of the string “Hello” that has an occurrence of the string “World” anywhere on the next line.

When the “Use regular expressions” checkbox is checked, the regular expression builder will appear next to the Find field. Clicking this will give some examples for building regular expressions as well as a link to the documentation.

What’s Next

Now that the Find in Files experience has been reimplemented to use the newer patterns of Visual Studio, we’re going to be able to provide more of the features we get asked for. We’d love to hear your experiences with the new dialog. We’re always watching Developer Community, and we’ve got a survey specifically for collecting feedback on the new experience that you can answer here. We know there are features that aren’t available today and your feedback is how we’ll prioritize the rest of the features. If you’re running into problems or you think the new dialog isn’t working correctly, please send us feedback with the Give Feedback button in Visual Studio.

Dante Gagne
Dante Gagne

Senior Program Manager, Visual Studio

Follow Dante   

33 comments

  • Avatar
    Doug Richardson

    The biggest issue I’ve had with find in files is visual studio hanging (completely unresponsive). I work a lot with Unreal Engine 4 projects in the latest non-preview version of Visual Studio 2019. I haven’t tried out the preview yet, but I hope you managed to get whatever was causing the unresponsiveness fixed (my guess is some sort of blocking I/O on the UI thread).

    • Dante Gagne
      Dante Gagne

      The new Find in Files has been completely rewritten and I know that part of the improvement was getting some of the code off the UI thread. I would highly encourage you to try the new experience. If the new experience is still locking up, please reach out to me directly! (DanteG@microsoft.com)

    • Avatar
      Jim Lehmer

      Yes, this. It has come and gone and come back over the last few dot releases. And saying “Use preview releases” in an enterprise environment is a non-starter. Yes, it’s great they’re rewriting it, but in the meantime Find and Replace across files, one of the most basic modern editor requirements, is broken.

      • Dante Gagne
        Dante Gagne

        Jim, I absolutely agree with you. We’ve released the new experience in the Preview channel so that we can make sure it’s stable enough to put into the release channel. The new feature will be available in the release channel soon (once we’re confident in it), so I’m sorry you’re running into these issues.

  • Avatar
    Hristo Hristov

    It is still not possible to remove custom items in “File Types” and other drop-down boxes. This was reported ages ago as a feature request. So many softwares have this issue of not allowing to delete old stored custom auto-complete items easily . An “X” option next to an item would be marvelous!

    Next can we have an option to keep the dialog open even on ENTER/Find All.

    BTW. My first experience after I entered my data and pressed ENTER was a VS crash.

    • Dante Gagne
      Dante Gagne

      Hey Hristo,

      Thanks for reaching out. Clearing out the MRU has been requested a couple times and it’s on my backlog of things to investigate. I certainly can’t make any promises, but we’ll see.

      As for keeping the dialog open, have you tried docking the window? I have mine docked particularly since I have a tendency to search, tweak a property and want to search again. However, we’re also investigating a button to bring the FiF dialog back up by clicking a button in any results window and have the dialog come back with the search properties that the given results window was populated with. That way, you could do 3 or 4 searches and still get back to an old search.

      As for the VS crash, I’m hoping that crash data is in our database. I haven’t heard many folks complain about crashes, so I’d like to know what happened there. Feel free to reach out to me (DanteG@microsoft.com) with as much data as you can share and I’d like to see if we can resolve that.

      • Avatar
        Hristo Hristov

        Thank you for the answer. I haven’t tried docking the window. I would prefer to have it undocked. I use several IDEs which allow me to keep the search dialog open as long as I need. Specifically in these projects I often need to do multiple searches one of the another. So having the search dialog open at all times saves on clicks. I don’t use very large monitors so docking the window will take up screen estate but I have three monitors so I prefer to move the search window to a side monitor. So I’d prefer if there is a checkbox (Search again) option to keep the window open as long as desired.

        About the hang – the IDE hangs sometimes shortly after I open a project but I am not able to tell under what circumstances, e.g. I try to search CMAKE_CXX_COMPILER in a CMake project with File type set to *.cmake;*.txt

  • Avatar
    Florian Schmitz

    While you are at it, can you please fix a long standing annoyance? When opening the search (using Ctrl+Shift+F for example), it will use the character next to the current cursor position as search subject. Which often is a “{“, “}” or “;” and completely useless. I know you can disable this, but then situations that actually make sense (like selecting a word in the editor and then starting search) will no longer work either…

  • Avatar
    Radek Kolář

    The buttons (Find next, Find all, etc.) are currently located at the bottom of the tool window. Having the Find and Replace tool window docked to the side of the VS IDE, ie. typically using the full height of the screen, the buttons are “too far away” from the other controls in the tool window. Please consider moving the buttons just under the other controls (eg. under the File types dropdown). Thanks.

      • Avatar
        Yann Duran

        but before we deprecate the old experience, we want to make sure the new version is meeting the needs of our users

        I applaud this attitude! Sadly lately it’s been more the exception than the rule for VS team members.

        Some other program managers haven’t been putting “the needs of their users” ahead of their own pet projects, but instead forcing horrible new or redesigned “features” on us, then refusing to let us go back to what they replaced despite overwhelmingly negative feedback for their idea.

        I hope you will continue to listen to user feedback and put our needs first. Thank you!

  • Avatar
    Zehev Spitz

    Does this mean standard editing shortcuts (such as CTRL+BACKSPACE to delete the previous word) will now work properly within the dialog? The current Find/Replace in Files dialog inserts a square every time I do this.

  • Avatar
    Jan Ringoš

    An idea: Language style-agnostic search:
    – Ignoring whitespace differences, “void func( a, b )” == “void func (a ,b)”, possibly even new-lines.
    – Ignoring braces where optional, “if (a) b;” == “if (a) { b; }”
    – Maybe even ignore redundant or order of qualifiers, “long signed static” finds “static int signed long”

  • Avatar
    dandy

    Fantastic. Just what I didn’t ask for.

    I’ve been using that search feature in VS for years since the one in Windows itself has been broken forever.

    If I add “abc” to a .txt file and save it, then immediately use the Windows search for “abc”, it’s not found, because I have to wait until everything gets reindexed because someone at MS decided that the technology behind a web search engine could be applied to a desktop. It doesn’t. If it happens to be a binary file, then forget it, it’ll *never* be found.

    VS does NOT try to be too smart for its own good. If I save “abc” to a file, then search for “abc” in VS, then it comes back. Maybe slowly, but it does – and this is what matters to me.

    Please Microsoft, don’t try to “improve” the search feature in VS to the point where it can no longer find anything.

  • Avatar
    Stephen Kaylor

    Please focus on making it much more keyboard friendly. The amount of clicking around in it I routinely have to do: switching from Entire Solution to Current Project, switching from *.cs to *.js (but not *.min.js!), toggling regex… is terribly painful.

    Having a saved “profile” (e.g. regex off, case sensitive, *.js but not *.min.js, Entire Solution) and then being able to summon it with a shortcut like Ctrl+Shift+1 for “1st saved profile” would be great. And keeping the focus on the Find What text box so I can Ctrl+Shift+F, Ctrl+Shift+1, enter my query, and press Enter.

Leave a comment