Add an option to disable closing open files that are removed from the directory

[noedlm]

• VSCode Version: 1.4
• OS Version: Windows 10

The main scenario here is when the user switches git branches where the starting branch has a file that the branch being switched to does not. What I'm seeing is the file in question is removed from the open editor. I would like for that file to remain open, just unsaved. Similar to how Sublime handles it.

might be similar to issue #101

steps to reproduce:

• add new file to git branch, leave the file open in the editor
• switch branches to one that doesn't have the file

expected behavior:
file remains open in editor unsaved.

actual behavior:
file is removed from the editor.

[bpasero]

If we do this I will get the exact opposite bug that users complain a tab is not closed when a file is deleted :)

[noedlm]

could you implement it as a setting that can be overridden at the user/workspace settings?

[jcam3ron]

+1 This feature in Sublime text has saved my ass once or twice when I've accidentally deleted a file I was using.

VS Code's auto-save feature comes close to this, but doesn't deliver the same functionality as Sublime. While an auto-saved file stays open after the file has been deleted, when you change tabs the contents disappears and an error is displayed.

[ronjouch]

Adding more than a 👍, because I feel this issue deserves reconsideration, and I have a proposal to reconciliate @bpasero's point of view with our pain.

First, to synthesize:

• @bpasero point of view that "If we do this I will get the exact opposite bug that users complain a tab is not closed when a file is deleted :)" makes total sense for the use case of a user casually editing a single file.
• But it's the Git use case mentioned by @noedlm in the issue description that makes sense: suppose I have, say, 12 various files open from a initialbranch git branch.
  → One git checkout otherbranch (where these files don't exist) later, vscode closes all 12 tabs, and when I come back to initialbranch, the pain is on me to re-open these 12 files :-/

In Sublime/Atom, the editor tab status communicates the file is dirty, but as soon as the file is back and in the same state as initially, the dirty tab flag disappears and I can keep on hacking on initialbranch. Smooth.

Proposal

• A dialog asking "close/keep"? Doesn't feel that great...
• Better: what about preserving the current approach, but displaying a non-modal, non-interrupting top-of-the-screen prompt asking "Code closed 12 files that disappeared. [Okay], [Re-open]" ?
  That feels better to me, because less interrupting; in the spirit of Gmail's forgiveness-rather-than-permission "Undo".

What do you think?

[bpasero]

I looked into this and I am hitting an issue that is kind of blocking. First of all, what other editors seem to do is:

• if you delete or move a file from within the application, any opened tab is updated (e.g. closed when deleted, updated when moved)
• if you delete or move a file outside of the application, the tab turns dirty (this means that renaming a file from foo.ts to bar.ts will show foo.ts as dirty even though it has been renamed - main reason for this is that it is hard to track file renames from external applications, they show up as DELETE and ADD)

My idea was to introduce a new setting workbench.editor.closeOnExternalFileDelete that is true by default:

Controls if editors showing a file should close automatically when it is deleted or renamed by some other process. Disabling this will keep the editor open as dirty. Note that deleting from within the application will always close the editor and that dirty files will never close to preserve your data.

Now this works fine up to a certain point: imagine you have 2 tabs open foo.ts and bar.ts. You restart and the 2 tabs are still opened, but in Code, only the first tab is actually loaded into memory (because the file is displayed in the editor). The second tab is not loaded until you click on it. Now imagine you delete the second, not active tab from an external process (bar.ts). I cannot keep the tab open, nor mark it dirty because at this time I do not have the contents of the file anymore.

Interestingly ST seems to have solved this, I can only imagine that tabs which are open are loaded from disk into memory (which is ugly).

Not sure what to do for this case, it is also ugly to close tabs that are not loaded.

[bpasero]

Btw for those people that randomly see tabs closing even though the file is still there, please see #13665 (comment) for helping me out finding the underlying issue.

[bpasero]

I pushed a change to introduce a new setting "workbench.editor.closeOnExternalFileDelete" that is by default set to true. If you flip it to false, there is some interesting things happening:

• deleting a file outside Code will no longer cause the file to close if opened (note that for this to work the file has to be opened at least once during the session, otherwise we do not know the contents of the file)
• instead of closing, the file will now show up as dirty
• as long as the file is not changed in this state, the file will move out of dirty state when restoring the file on disk

There are some underlying implications as well in this state:

• a file that became dirty because its underlying file got deleted will show a dirty indicator even if auto save is enabled
• the file will also never auto save (e.g. on focus change, after delay) because this would mean to bring back the file too easily. instead, an explicit save by the user is required to restore the file

This needs some good testing, so feedback welcome (will be in tomorrows insider build).

[bpasero]

Reopening based on some feedback from the team which I want to capture here (without opinion):

• it seems weird that we keep the editor open as dirty only when the file gets deleted but not when it gets changed on disk (without delete)
• the behaviour of orphaned file models when auto save is enabled is not very clear and might be confusing
• instead of forcing the user to get dirty files on delete, we should maybe rather find a way to keep the tab open and show a message that the file was deleted on disk. if the file comes back, we can restore the contents again

[ronjouch]

By the way, Atom 1.15 is at it too:

Tabs of deleted files are retained

By popular demand Atom will now keep open the tab of any file, modified or not, when it’s deleted outside the editor. You can turn off this behavior with a new core setting:

[bpasero]

One of the main concerns we have to solve is if marking such a deleted file as dirty is a good decision. It may draw the wrong impression to the user because so far we only show the dirty indicator when changes have been made by the user. Happy to hear thoughts from people subscribed to this issue on that topic.

[noedlm]

Personally, I've seen the functionality being discussed here in other IDEs and have grown accustomed to it. With that said, given such scenario, if vs code does a Save As when the user tries to save the file (because it's marked dirty), it isn't really a drawback or inconvenience in my opinion. And I can safely assume the majority of the community using vs code is rather tech savvy and would know what's going on.

[bpasero]

After lots of feedback from the team and discussion, we settled on a solution that does NOT mark the editor as dirty but just indicate to the user that the file has been deleted on disk:

Marking the file as dirty has some consequences that we are worried about:

• suddenly the file participates in hot exit even though it does not contain changes made by the user
• a dirty indicator could be confused with the need to save the file to preserve a users work which would restore a deleted file which may have been deleted for a good reason (e.g. a branch switch)

Imho this setting should eventually be the new default, but I want to give it some more testing and feedback.

The setting is now called: workbench.editor.closeOnFileDelete