4 ms·
Basically, it closed a buffer because the backing file disappeared when I checked out a different branch. So I guess the lesson is use your file system to retai
by whipoodle 9y ago
Basically, it closed a buffer because the backing file disappeared when I checked out a different branch. So I guess the lesson is use your file system to retain data and never your editor, which sounds obvious and you could certainly argue the loss was my fault. But I do that all the time with Sublime and never had this problem once. In fact I could quit Sublime altogether and the data would still be there when Sublime reopened.
Basically, I can see how the choice they made is a reasonable one, but my stance is a buffer should never close until I say so. If the backing file disappears, the last contents of the buffer should stay in there until I close it.
I bet a lot of people will never get bit by this, but it's nasty enough that I think they should reconsider this decision. But for me it doesn't matter, I don't want to lose work because I trusted my editor to hold on to something and it didn't, so I'll likely never use it again.
- betenoire 9y agoI think every editor can probably configured to do this. I've set up my VIM to do this specifically (auto reload the buffer when the file is modified). I don't think that one's on VSCode.
- _tulpa 9y agoThey're not configured to do that by default, most of them ask prompt you if a file changes. This one is on VSCode for having unsafe default behaviour which is also different to pretty much all the other editors.
- bpasero 9y agoVS Code will never close a buffer that has changes (e.g. is dirty). In this case, the buffer was closed because the editor was not dirty. You can change this by configuring "workbench.editor.closeOnFileDelete": false
- nerdponx 9y agoHaving that default to "true" is really silly. VSCode is OSS right? That seems like a mulligan pull request to me. I can't imagine anyone is relying on the default behavior as-is.