4 ms·
Well, that's not very positive... but I can relate. VS Code lost some work of mine on the first day I tried it, so I decided not to continue using it. It wasn't
by whipoodle 9y ago
Well, that's not very positive... but I can relate. VS Code lost some work of mine on the first day I tried it, so I decided not to continue using it. It wasn't super important so I wasn't angry, but it was a good chunk of code I had just spent probably 45 minutes writing and debugging.
You could argue it was my fault because I didn't stage and commit the new file, but there's no reason to close a buffer just because the backing file is gone. Close it if I say so, otherwise keep it open with the last-seen contents of the file. This has always worked fine in Sublime.
Please always err on the side of not losing data, even if it means keeping around "annoying" extra tabs.
- devrandomguy 9y agoExcessive automation considered harmful: even if you want something to happen 99% of the time, it should still be a manual operation. Otherwise, it will bite 100 of your 10,000 users at least once.
- whipoodle 9y agoIf it's a destructive operation, yeah. I was really, genuinely surprised that their editor works like that. As you say, it's not something that will bite you often, but when it bites, it could be pretty painful.
- joaomoreno 9y agoActually you can control this behaviour with "workbench.editor.closeOnFileDelete": false