Modernizing Find in Files
Dante Gagne
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.
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.
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
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.
Light
Dark
35 comments
It would be great to have one click option to add all extensions in SLN into file-filter line, so I can just remove what I do not like, and do not need to think-up what extensions might my SLN contain…
That’s an interesting idea. I worry that it would flood the box with too many file types, but some sort of experience that allows you to pick the extensions you like and the ones you don’t is a good idea. If you don’t mind, can you suggest that on Developer Community? https://developercommunity.visualstudio.com/
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).
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)
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.
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.
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.
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.
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
There seems to be alot of free space on that window, so a tip could be added about these search patterns.
Also I have just remembered that Visual Studio Code has a separate Exclude files edit box.
I just reported this issue via the issue reporting tool and tried to capture the repro steps. I hope this helps.
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…
Oh yes please. That happens all the time, it’s so annoying.
If anyone’s got a bug or suggestion reported on this already, please post the link here so that we can follow up on it.
YES, I do this way more than I should.
If folks want to give upvotes, the item in Developer Community is here:
https://developercommunity.visualstudio.com/content/idea/368695/find-and-replace-dont-fill-with-the-text-near-the.html
Thanks
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.
I just hope it will be more convincing than the “Redesigning the New Project Dialog” horrible butchery that we have to live with, now.
I’ll ask you to be the judge of that. If you have feedback, I’m always listening. The best place, of course is https://developercommunity.visualstudio.com/
“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!
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.
Yes. It works (™).
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”
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.
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.
I’m not satisfied with the keyboard model that was released in the first round. That’s absolutely something I want to get working correctly.
The terms “miscellaneous files” and “external files” make sense when you read a blog, but I’d bet that very few developers (other than the PM who spec’ed the feature of course) will have an easy time realizing what they mean. Why not choose a simpler text, such as “Include files not in solution” or something? It’s not like the dialog box lacks horizontal space.
It would be great to have a checkbox in the results tab to track changes and auto update results (line numbers) while the code is being updated.
I use the find to look for parts of code that I need to update or delete, but when the code is updated, then the line numbers change and when I click on references the line that it takes me to has changed and I need to re-run the query.
Roberto, it’s not exactly the same thing, but we do have an existing suggestion to allow for a Refresh in the Find in Files:
https://developercommunity.visualstudio.com/content/idea/589635/add-a-refresh-button-to-find-results-tabs.html
If you wouldn’t mind upvoting that and adding your feelings to the thread, that would be great.
It would be great to have a checkbox ‘Ignore comments’ instead of having to use regular expressions.
Gabriel, this is a frequent ask:
https://developercommunity.visualstudio.com/content/idea/368691/find-and-replace-add-options-to-exclude-lines-with.html
The core problem is that Find in Files doesn’t submit the files it’s searching to the language service. And without the language service analysis, we don’t have a reliable way to know which lines are in comments and which are not. We’ve gotten tons of feedback that the speed of the search is the top priority, and allowing this functionality would have significant impact on the speed.
Please upvote and add your comments to the thread above (We’ve actually been exploring some options on how to do this), and any feedback we get is really useful.
This is the same as the destroyed “New Project” dialog or the destroyed “Start Page”?
Is now the turn to destroy the “Find Files” dialog?
Why modernizing means ugly for Microsoft? The new project dialog is flat, plain and ugly, instead of the actual grayed and degrade 3d buttons, text boxes, checkboxes, etc. Looks ugly like all Windows 10.
Biggest problem with Find in Files – that VS constantly positions the caret in the Find Results to the end of the list. So let’s say I search for “foreach”, and within 10 hits, I (quickly) see the file I’m after, so I try to click the item. Except, VS has scrolled the text down 50+ lines as another back of search results comes in. I lump this into a general “VS keeps changing user focus without corresponding user inputs” problem area – leave focus alone! I’m quite often doing something as I wait for VS to finish some other (async) task I asked it to do, but when VS starts moving things around simultaneously, it makes for a VERY frustrating experience (the toolbar mess is another area where this general VS behavior is a headache…it’s like the VS team only has a single usage scenario – 1. User clicks button, 2. User waits for task to finish + additional time to account for a usual lack of “I’m finished” cue, 3. Once UI task(s) finishes, user *then* goes to finish any other tasks, totally happy that s/he has to work serially in 2019.
Another one would have to be the inconsisteny wrt the initial field that VS sets user input focus to…Find puts user focus in “Find what”, while Replace starts you in “Replace with”. NOTE: “Find what” is not always populated with the correct text, since it likes to insert highlighted text there automatically, so my frustration lies in the inconsistency – I’d rather the two different functions flow almost identically, given that they share a UI.
I hope this new find will allow me to easily search all file folders under the tree I’m viewing in Solution Explorer. If I click “Scope to This” in the solution explorer to limit my view of the tree, search should easily allow me search just those files. This is particularly important with web projects that aren’t part of a solution.
There appears to be a serious bug in the new find in file functionality. When you have a debug session open (doesn’t even need to be on a breakpoint) and you do a “Find All”, Visual Studio locks-up and you need to kill it through Task Manager. See my report at https://developercommunity.visualstudio.com/content/problem/851034/executing-search-while-debugging-locks-up-visual-s.html