Suffer from Ctrl+S fatigue? We have a feature for you
Dante Gagne
The idea of the “Integrated Development Experience” is a tool that brings all the systems a developer needs to develop their application into a single place. Coding, debugging, publishing, profiling… these are all tools that Visual Studio brings to our developers. Just as a general contractor doesn’t solve every problem with a hammer, however, we’re aware that Visual Studio isn’t the only tool in the developer toolkit.
One pain point we’ve been hearing about more and more is one that comes up when switching from one tool to another. Specifically, when you arrive at your other tool if you’ve been using Visual Studio without saving your code, that code shown in your other tool may be out of date. Then, when you edit the code in the other tool, your code is out of sync and it’s an ordeal trying to put everything back together.
Starting with 17.2 Preview 1, the new autosave feature will help with this. Use Visual Studio Search (Ctrl+Q) and look for “autosave”. That will take you to the Environment\Documents page in Tools\Options.
If “Automatically save files when Visual Studio is in the background” is checked, any time Visual Studio loses focus, usually as you change to another application in Windows, VS will attempt to save every dirty document in the IDE. This will include project files, solution files and even miscellaneous files that aren’t part of the project or solution. If saving a file fails for any reason (for instance, the file is read-only on disc), Visual Studio will keep your changes in the editor and simply leave the file dirty. The intent is that when you switch to another tool, after a moment, all your changes in VS will be committed to disk. While most developers will benefit from this, code files on slower disks or on remote servers will make a lot more save operations, and developers should keep that fact in mind when enabling autosave.
It’s worth mentioning that folks who are taking advantage of the “Code Cleanup on Save” feature from 17.1 will find that autosave does not trigger a Code Cleanup. We felt that it would be somewhat disruptive if it happened too often. Code Cleanup on Save will only trigger when you explicitly save the file, either through a command like Ctrl+S or implicitly as part of a build.
What do you think?
We’ve had suggestions in the past that some developers would like an even more aggressive autosave mechanism. Some developers would like Visual Studio to commit their changes to disk when Visual Studio goes idle after a set amount of time has passed. Another suggestion is to save when switching documents. If you’re the kind of developer who would find that useful, we’d love to hear from you. You can join the conversation here.
Please let us know how this feature works for you. Are you using it? Is it being too aggressive or not aggressive enough? How could we improve it? Please let us know your thoughts. We read all the suggestions provided on Developer Community as well as the comments on this blog post.
Light
Dark
28 comments
Nah.. I love being in full control of the file I am editing. The file I am working on should only be saved if I give the command to do so. I turned off this kind of autosave thing on PhpStorm and Android Studio.
Is there even a thing which is called Ctrl+S fatique? Also isn’t it bad to save automatically on each Alt+Tab? It gives unnecessary stress to the HDD/SSD. They can stay on RAM just fine.
There was ctrl-s fatigue once, back when we used it to stop text scrolling on a window. (I found it funny that the article references ctrl-q, too, which I think was what we used to start the text scrolling again.)
People in general seem to want saving to be done for them. MS Office has been saving backups for eons, since before SSDs. Cloud applications save constantly. Even games save for you frequently. I’m not surprised that VS is starting to head the same way.
For me, the new feature isn’t going to matter. I had enough blue screens in my formative years that I control-S every couple of minutes anyway.
This is a very welcome feature. I flip between VS Code and VS2022 all day and often forget to save in VS. VS Code can save as you type, which should also be an option here in my opinion.
VS Code provides options to save on a time interval, on loss of focus and… I think there’s a third option. We’re investigating more of those options for VS as well. There’s a link to DeveloperCommunity above (and I just put it here too) to upvote other types of Autosave. Please head over there and lend your votes and voice. 🙂
Theoretically a nice idea to not forget saving.
The real world is different from that: When I work with a document I don’t want that it overwrites my existing file until I tell it to do so. Sometimes I test something and in the end decide, that it’s not so good than the old version, so if Undo goes not far enough into the past, I can throw it away and reload my old file. Which is gone because of autosave….
(By the way, same thing with other autosave applications like Office or even Windows system settings where I can’t simply press Cancel to not apply any of my changes.)
Of course I’m aware that I can enable the history function of Windows to have access to previous versions – but I don’t want that for the whole file system just to have a backup for some development files, so this is disabled always.
Of course I know that I can make a backup of my file before I start doing changes, but not so rare I forgot to do that.
So a better way of sharing the same file in different tools would be a RAM copy of my file which could be changed from any tool using what we had long time ago: A RAM disk. So whenever I open a file in VS, it is copied to the RAM disk and can then be changed in any tool by opening the file from there. Then an autosave only saves the file to the RAM disk, and so all other tools could do – without changing the file on disk. (As a security mechanism, the whole RAM disk could have a backup on disk similar to the Windows page file so everything is still existing if my computer crashes for any reason.)
Now every tool could work together on the same file and saving it on one could allow them to reload it at another (example: Notepad++ automatically detects when the file was changed outside the editor and allow to reload it). All tools would not change the original file but only the file in RAM disk. In VS you could then have a second save command to save the RAM version to the original place which VS knows as it was loaded from there.
Advantages:
– I can revert at any time to the original file
– Working with the file is faster as it is in RAM
– Other tools needs no change as it is a “normal” file in an additional drive letter (the RAM disk)
– Automatic backup of my file (RAM disk backup) without overwriting my original file so no fear to loose anything
– Windows file versioning could be used on a RAM disk also
– I have a real effect (as you described above) using this new autosave function as it would be saved in the RAM disk only without losing my original file until I decide to save it there
Technology is already existing, VS would only need to start the RAM disk while loading (if not already started) and offer a second command to save the file from RAM disk state to normal disk. RAM disk integration in Windows would be the perfect way to also use it for faster temp files etc.
A second “dirty” status comparing the RAM disk version with the saved file on harddisk can show if the version on disk is current and need to be saved. VS could also show a comparison window to see the changes from the version on disk and the version in RAM disk.
Just some idead to improve working with files… (and would be also great to use the same feature for any other application of course).
you should get some vcs
Of course a possible way to go, but I really don’t like VCS tools.
And I do not want to setup a VCS project each time I work with a single file I opened in VS. An autosave destroys the original file in that case (or I switch it off, then the function is also useles…).
We know that not everyone wants Autosave. That’s why the feature is *NOT* enabled by default and as far as I’m concerned, it feels like an option that folks should opt INTO. So, if it’s not for you, I completely get it. However, there are many folks who have requested this and I’m happy to finally make it available.
Enabling this would only change where I end up being gotcha-ed; but without the easy ability to get back to the prior state. On the plus side I wouldn’t end up forgetting to include some last minute comments/whitespace cleanup when committing code via my external git client. On the down side, there are also cases where I find myself deciding that whatever code I spent the last 10 minutes typing is experimental/risky enough, that I want to do a local commit of what I had pre-edit to make rolling back easier. Likewise for cases where I decide I went down a completely wrong path, and want to revert to what I had across at the time of the last save in which case playing games with git (git commit, VS save, git discard changes) is my default solution.
This is a great feature for those that need it. It’s also amazing to know that the VS Team recognizes that not everyone operates the same way and features like this should be optional, not forced.
I think the whole “create a ~$ prepended file that has constantly saved ‘dirty data’ that if something happens and the file is reloaded without a proper save/discard asks if you want to resume from your dirty data” like what Office does would be another route to take. That would allow for another set of users to get covered in case Windows decides to restart or there’s a crash of any sort.
Honestly, I have more ctrl+z than ctrl+s fatigue. The whole “select some text, ctrl+h to find and replace, realize that it switched from ‘selection’ to ‘document’ for no apparently reason” thing has bitten me more than once over the last few months. Sometimes I don’t notice till I’ve done several other things, then clicking x and -not- saving is my safest path.
Hi Jason! I’m Denizhan, PM on Visual Studio responsible for search and navigation.
I’m interested in the replace situation outlined above. If some text is selected and you enter ctrl + h, the replace box should only replace text in the selected area. Can you tell me more about when this is not the case?
It’s pretty easy to find in developercommunity.visualstudio.com. Here’s two I’m familiar with.
https://developercommunity.visualstudio.com/t/It-is-impossible-to-search-on-selection/1512668
https://developercommunity.visualstudio.com/t/Find-and-Replace-with-Selection-Bug-Vis/1549735
There’s been a few fixes, but it seems to creep back up at random times. I’m just having to be extra careful. In most cases when I experience it I’m not in a position to stop the work I’m doing to attempt to submit a report(which likely I wouldn’t be able to reproduce since it’s so random). For the longest time I thought I was crazy until it was doing it nearly every time and I went searching and found others complaining.
My point was “auto-saving can be horrible for some of us, very glad it’s optional”
Hey Denizhan. I just got burned a few times on the whole thing I was talking about. Every single one of the VS bug reports have been closed. Most “duplicate moved to” and moved to one that is closed. I went ahead and recorded a gif of what goes on and why it’s so damned annoying.
Find+Replace keeps switching to “Current Document” even if text selected
Off-topic: When did “Integrated Development Environment” get rechristened to “* Experience”?
Probably, when woke millenials took over MS. In any case, VS is suffering what I call “dead by features”. In a year, they won’t remember all these shenanigans they are happily adding now.
Hmmm… apparently it get rechristened to a typo. I’m somewhat amused that I didn’t catch that. Yes, it should be an integrated development environment. No idea where Experience came from.
I’m with many others here in that I won’t be using this feature as it causes more problems to me than it solves. Even when using source control I often make changes to files that I may or may not want to keep and it would be bad if I suddenly got a chat or voice call from my boss, or perhaps an Outlook notification about an upcoming meeting in the middle of my VS screen; switched over to dismiss/answer and then VS auto-saved my changes. Now I have no way of knowing what changes I’ve made that I wanted to keep vs didn’t. Sometimes I’m using the current file as a scratchpad for code syntax that I need elsewhere. Yes Undo (or revert changes in Git) would work in some cases but closing the file is just faster.
I also don’t really understand the user scenario given for this feature. Are there really people who are editing the same file in multiple apps at the same time? Why? The only real use case I can see is if somebody types in some code and then switches to the command line to do something (or more likely the CLI does something in response to a file change). In this case though it would be unclear to me whether VS has saved the file such that the CLI does its thing or not yet.
Before this feature would be even remotely useful to me I’d need VS to provide “yet another” indicator of the changes it auto-saved vs those that I have already made (in the margin) AND provide a way to jump back to my “unsaved” version without manually undoing (which is a pain).
> The only real use case I can see is if somebody types in some code and then switches to the command line to do something
One example is committing to a VCS from the command line. I have more than once forgotten to save my last change before switching to the command line to commit. This saves me the hassle of fixing that after the fact.
One of the other use cases we’ve heard from folks is when they prefer VS Code for editing some file types and VS for others. VS Code already has an autosave feature, so folks will edit over there for some file types, then jump to VS. VS Code would autosave as soon as you switch to VS. But trying to go the other way didn’t work.
The VCS solution is absolutely another one, and there are many folks who use external tools alongside VS. The goal is to try, where we can, to streamline that process as best we can.
When we asked the VS Code folks how many people used Autosave, the numbers on aggregate were higher than I predicted. If that many people wanted the feature, it was worth investigating on our side.
Yup.. Most of the time, even with git or version control, closing and reopening the file is much faster, when I think I messed during the last five minutes. Auto saving (into the real file) is an inconvenience, not a convenience. I am glad to hear that it’s opt in feature, not the default feature, as in other IDEs. As for the fear of crashing / BSOD, the way Microsoft Word and Excel handled it is correct already.
Bonjour,
Je viens de faire la mise à jour et je suis toujours en 17.1.2. Je n’ai pas l’option.
The feature is available in 17.2 preview 1 (17.2.1). It looks like you’re on 17.1.2, so you’ll need to update to the newest preview.
Adding a controversial feature like autosave, but then you see there are critical issues like https://developercommunity.visualstudio.com/t/1593340 causing people to be unable to use 2022 at all, that haven’t had an update in 4 months.
Priorities?
Priorities? They have it. Probably, inverted.
I downloaded Visual Studio 2022 about 2 months ago, and have been writing code since downloading the software. I have noticed something that rather bothers me somewhat. In previous versions of Visual Studio, when I successfully compiled a project, it automatically generated an application (.exe) file. In Visual Studio 2022, I have noticed that the application (.exe) file is no longer being generated. Am I missing something in the software setup or something? Is there something that I need to do to get Visual Studio 2022 to automatically generate the application (.exe) files when a project is successfully compiled without having to rely on 3rd party software in order to get an application (.exe) file?
It would be nice if this feature was added back into Visual Studio the way it was in previous versions of the software, so that when a project is successfully compiled, it generates the corresponding application (.exe) file.
Am keen to try for a hot reload scenario (external tooling). One thing I’ve noticed is that it doesn’t behave the same as Ctrl+Shift+S in that extensions don’t execute. I have the Whitespace Visualizer extension installed, which strips unnecessary whitespace when saving. It works fine with Ctrl+Shift+S, but not with this feature.
Also, I’m very doubtful that I will want this feature on for all solutions in the long term as it will probably cause me a bunch of confusion. It really feels like it should be on a per solution basis.
Thanks for the feedback. Would you mind suggesting that here? I’d love to capture this suggestion.
The way Autosave is designed is that extensions need to opt into saves invoked via autosave. We were actively concerned that if extensions were being too aggressive here, it might result in some very uncomfortable situations, particularly if we extend autosave to act on a timer or on idle. Right now, we’re finalizing a few pieces of this story, so I don’t believe we’ve got the documentation available for extension authors to connect to the Autosave, but we should be providing that soon.
A good2have feature if that’s your style. My style, however, is smashing that Ctrl+S like it owes me money, whether I’m in Word, Notepad or VS/VS Code or Photoshop, and I’m ok staying with that 🙂