Provide option to allow keeping open deleted tabs

[vjpr]

I have some testing code that regenerates a directory structure each run. I would like to keep a tab open to observe the changes to the file when it is regenerated.

This make its difficult to check changes from generated files, such as transpilation output, etc.

After #160, the tab is removed, even though it is regenerated again within seconds, before the window gets focus again.

Sublime Text keeps them open, and only updates on focus.

I think there should be an option to allow only refreshing/deleting tabs on window focus.

[jonathankoren]

The problem with automatically deleting a tab even if the buffer is unchanged, is that the buffer becomes the only copy of the work. It's very odd that a destructive action doesn't require confirmation. I've lost work because of this.

[lemire]

Reposting my comment from another issue:

Suppose that you have opened some file generated by a system. This system does its work concurrently which may involve changing, deleting or moving files. You are reading the file... and then, all of a sudden, the text you are reading goes away... without any kind of warning.

I think that this behavior would take most users by surprise. Taking users by surprise is not good.

The ugly workaround is that you have to make copies, then open the copy in Atom. But an in-memory buffer is already a copy.

[lemire]

Suppose you have a file opened in Eclipse, Microsoft Word, or just about anything that looks like an editor, and the file on disk is deleted by another system, I think you will find that the in-memory buffer is not automatically flushed.

Thus I argue that Atom's behavior is surprising.

We can argue about what behavior is best, but I would strongly argue against surprises.

[Anthropic]

I often have to swap source control revision, working on a large corporate app with a bunch of active branches. I recently switched from Sublime, where a change of branch would leave files open that were no longer in the file system and when I switched back I could continue editing.

Now I find the files in the editor are closed or if unsaved they're re-named in their tab from package.json to package.json-c5c53cf0, so now every time I swap back my branch I have to use save as if I had forgotten to save all changes prior to branch swapping.

What a painful and unacceptably messy user experience.

Sublime got this right and Atom needs fixing urgently IMO.

[awkaiser]

Adding to the above points and scenarios: Some day, probably a busy one when you're moving way too fast and haven't had your ☕ , rm -rf on the wrong directory (or equivalent disaster) will happen. I've lost uncommitted work in an accidentally nuked local working copy of a Git repository, which would have been simple to recover from had Atom not helpfully closed all related file buffers. Fresh clone, save files, done. I was lucky, in that I had recently committed and pushed changes to the remote (always a good habit), and wasn't too far behind where I left off, but others may not be so fortunate.

I agree that Atom's current behavior is surprising, and think that this should be a configurable preference, further arguing that the default should be that buffers remain open. We don't need to argue if it's a toggle preference, and "no surprises" (as @lemire said) does sound like the sensible default to me.

[lemire]

Let me clarify the issue so that it is clearer to everyone:

Description

Currently, Atom removes and deletes a tab whenever the corresponding file on disk is deleted.

It is surprising to delete an in-memory buffer (an Atom tab) without giving the user any chance to save their work. This is surprising because no other editor, IDE or word processor works this way. It is always understood that the in-memory copy is distinct conceptually from the persisted copy on disk.

This is a new behaviour introduced by the following issue ...

#160

It was raised by @adambuczynski because "deleting an unedited file from within Atom which had it's tab open caused you to have to jump through 4 different hoops". That is, Atom made it difficult to delete a file within Atom. However, @adambuczynski agrees that "files being deleted externally are a different use case and should probably be handled differently".

Steps to Reproduce

• Create a new file in Atom and save it on disk as helloworld.c.
• Go in a shell or a file explorer and delete the file helloworld.c on disk.
• Observe that the tab containing the content of helloworld.c is deleted from from the Atom GUI.

Expected behavior: The tab should remain open, the in-memory content should remain so that the user can save it again, possibly elsewhere

Actual behavior: The in-memory content is lost whenever the on-disk content is deleted.

[adamreisnz]

As @lemire pointed out and as I mentioned in the other issue, my biggest problem at the time was with how annoying it was when you're deleting a file from within Atom. If you do that, you expect the file to go away and any tabs of that file to get closed. If you need to recover the file, you can get it from the trash or from your version control.

However, when that issue was addressed, the solution was applied globally, causing any deleted file (regardless of what actioned the delete) to close the tab and clear the buffer in Atom.

As people have since then pointed out, this has caused some problems for various use cases:

• Switching branches: files open in your editor that are not present on the branch you are switching to get closed automatically, because GIT is "deleting" the files from your working directory. Very annoying if you want to compare some files, or switching branches back and forth and have to reopen everything you were working on.
• Short lived log files: log files that are opened to inspect in Atom would get closed again if the log files is deleted via an external process. This is not ideal when you want to keep viewing the log file.
• Other external causes: files deleted not via Atom for any other reason which you may have had open and didn't want to close/lose.

From my point of view, instead of providing an option, it would probably be better and simpler if Atom would distinguish between "Atom initiated deletes" and any "External deletes".

If a user deletes a file via tree view in Atom, behave as it's doing now. There is already a confirmation dialog in place.

If an external process deletes a file, revert back to old behaviour, keeping the buffer/tab of the file open.

Correct me if I'm wrong, but since the Atom-initiated delete is easy to track (I think it can only be done from tree view, so just one command), it should be fairly simple to implement this?

[narayanpai]

@adambuczynski +1. I just moved from sublime to atom. Atom auto closing the file on its gui while switching branch is annoying. Badly in need of this feature, where it retains the tab with the file contents in its memory

[Anthropic]

@50Wliu sorry to tag you in this (you are in the atom org and made the last commit so you won) but as @adambuczynski points out above, this issue was caused by unintended side-effects to another issue and should really be marked as a regression (high priority in my opinion), do you know who we need to tag to raise the priority of this issue?

[winstliu]

/cc @iolsen, @mnquintana

[iolsen]

Thanks for raising this, @Anthropic. I agree this is surprising behavior and should be considered a bug. We'll look at this soon.

[Anthropic]

@50Wliu you rock!

@iolsen that's so great to hear, really looking forward to being able to use Atom as my main IDE again :)

[Anthropic]

@iolsen do you know what causes the tabs to re-name files after changing branches with a new extension like index.json**-9309511f**? Is it part of this issue or separate?

[iolsen]

@Anthropic I don't know, but thanks for mentioning it here. We'll look when we get to this issue.

[awkaiser]

@iolsen I came back to check in on this and see that it's been assigned and triaged today, but "in progress" since October 28th (atom/text-buffer#178). Really looking forward to this being patched!

🎆 Happy New Years! 🎆

[Anthropic]

And Sublime

[iolsen]

would prefer if the file name stays the same, so a simple Ctrl + S would save it back to where it was originally. I believe that's also how Notepad++ works on Windows.

I agree. I'll make that change.

[ungb]

@iolsen After testing on linux, with Atom 1.13.1(before your changes), here's the behavior I saw (there's no setting for deleted files in settings):

Linux

Test Case	Behavior
Delete from tree view closes corresponding file tab without error	Closes tab(Expected), No error
Open Atom, create new file, save it. Deleting file outside Atom follows setting.	File name is the same. Tab exist, file content still exist
Open Atom, open existing file. Deleting outside Atom follows setting.	File name is the same. Tab exist, file content still exist.
Open Atom project with existing files already open. Deleting outside Atom follows setting.	Closes tab

[adamreisnz]

@iolsen Seems to be working well on Mac 🎉

Mac

	Close Deleted File Tabs enabled	Close Deleted File Tabs disabled (default)
Delete from tree view closes corresponding file tab without error	PASS	PASS
Open Atom, create new file, save it. Deleting file outside Atom follows setting.	PASS	PASS
Open Atom, open existing file. Deleting outside Atom follows setting.	PASS	PASS
Open Atom project with existing files already open. Deleting outside Atom follows setting.	PASS	PASS
Open Atom project with an unsaved file preserved. Save it. Deleting outside Atom follows setting.	PASS	PASS

When the tab is preserved, the tab loses the file name and reverts to untitled which I think could be a problem when trying to identify buffers. Edit: I see @50Wliu already commented on that. I agree that it should keep the original file name.

I also think after install the Close deleted file tabs setting is disabled by default, not enabled.

[iolsen]

I also think after install the Close deleted file tabs setting is disabled by default, not enabled.

Yeah this is the intended behavior I just goofed on the table. (It's fixed now.)

Thanks for your help here! Glad your results are good. Still Looking into the Linux issues.

[adamreisnz]

Cool, no worries. Glad I could help.

[iolsen]

One more round with the latest fixes, which are now on master @ungb. For each platform:

	Close Deleted File Tabs enabled	Close Deleted File Tabs disabled (default)
Delete from tree view closes corresponding file tab without error (check JS console)	✅ or ❌
Open Atom, create new file, save it. Deleting file outside Atom follows setting.
Open Atom, open existing file. Deleting outside Atom follows setting.
Open Atom project with existing files already open. Deleting outside Atom follows setting.
Open Atom project with an unsaved file preserved. Save it. Deleting outside Atom follows setting.
Open Atom, create new file, save it. Modify it without saving. Deleting file outside Atom keeps buffer open.
Open Atom, open existing file. Modify it without saving. Deleting file outside Atom keeps buffer open.
Open Atom project with existing files already open. Modify it without saving. Deleting file outside Atom keeps buffer open.
Open Atom project with an unsaved file preserved. Save it. Modify it without saving. Deleting file outside Atom keeps buffer open.

[adamreisnz]

	Close Deleted File Tabs enabled	Close Deleted File Tabs disabled (default)
Delete from tree view closes corresponding file tab without error (check JS console)	✅	✅
Open Atom, create new file, save it. Deleting file outside Atom follows setting.	✅	❌ The file is not marked as modified after a delete, which allows you to close the tab without confirmation and lose all contents
Open Atom, open existing file. Deleting outside Atom follows setting.	✅	❌ The file is not marked as modified after a delete, which allows you to close the tab without confirmation and lose all contents.
Open Atom project with existing files already open. Deleting outside Atom follows setting.	✅	❌ The file is not marked as modified after a delete, which allows you to close the tab without confirmation and lose all contents.
Open Atom project with an unsaved file preserved. Save it. Deleting outside Atom follows setting.	✅	❌ The file is not marked as modified after a delete, which allows you to close the tab without confirmation and lose all contents.
Open Atom, create new file, save it. Modify it without saving. Deleting file outside Atom keeps buffer open.	✅	✅
Open Atom, open existing file. Modify it without saving. Deleting file outside Atom keeps buffer open.	✅	✅
Open Atom project with existing files already open. Modify it without saving. Deleting file outside Atom keeps buffer open.	✅	✅
Open Atom project with an unsaved file preserved. Save it. Modify it without saving. Deleting file outside Atom keeps buffer open.	✅	❌ The file is not marked as modified after **editing**, which allows you to close the tab without confirmation and lose all contents.

Ok so in general it is working well on OS X, but the items I've marked with a red cross are buggy. In particular the last item, I can reproduce this consistently. When I have a new unsaved file, and close the window, then re-open and save the file, any subsequent editing of this file does not mark it as modified, allowing me to close the tab without warning. Hence the same behaviour when removing outside of Atom.

The same goes for creating a new empty file, saving it, deleting it outside Atom. The file is not marked as modified, and subsequent editing of the buffer also doesn't mark it as modified.

Tested on Atom 1.15.0-dev-81e8ccc

[ungb]

Good find @adamreisnz!

For the last item and the scenario Open Atom project with an unsaved file preserved. Save it. Deleting outside Atom follows setting., I can repro the issue. the other scenarios I'm seeing the file as marked as modify after deleting.

(following scenarios are default settings)
Working Open Atom, create new file, save it. Deleting file outside Atom follows setting.:

Not working Open Atom project with an unsaved file preserved. Save it. Deleting outside Atom follows setting.:

The two scenarios I can repro have to do with Opening Atom project with an unsaved file preserved.

[ungb]

I've tested on the different os. Based on the test cases everything passed the different OS's.

I can repro the issue that @adamreisnz reported.

Another issue I saw was:

1. Open a project in terminal with atom .
2. Open a file and modify it, don't save.
3. Close Atom(this won't repro if there's other atom windows open. Only if all Atom instances are closed)
4. On the same directory in terminal, do atom <new file name>

Actual: Atom opens new file with the current folder. The changes on the file that was modify in step 2 are gone. When you close Atom and reopen with atom . or opening recent projects, it shows the new file from step 4 only.

Expected: old tabs and unsaved changes should exist(if there are any) and new file should open in new tab
This could probably be a completely different issue. In which case, I can create a issue for this. @iolsen

Test Results:

MAC

	Close Deleted File Tabs enabled	Close Deleted File Tabs disabled (default)
Delete from tree view closes corresponding file tab without error (check JS console)	✅	✅
Open Atom, create new file, save it. Deleting file outside Atom follows setting.	✅	✅
Open Atom, open existing file. Deleting outside Atom follows setting.	✅	✅
Open Atom project with existing files already open. Deleting outside Atom follows setting.	✅	✅
Open Atom project with an unsaved file preserved. Save it. Deleting outside Atom follows setting.	✅	✅
Open Atom, create new file, save it. Modify it without saving. Deleting file outside Atom keeps buffer open.	✅	✅
Open Atom, open existing file. Modify it without saving. Deleting file outside Atom keeps buffer open.	✅	✅
Open Atom project with existing files already open. Modify it without saving. Deleting file outside Atom keeps buffer open.	✅	✅
Open Atom project with an unsaved file preserved. Save it. Modify it without saving. Deleting file outside Atom keeps buffer open.	✅	✅

Windows

	Close Deleted File Tabs enabled	Close Deleted File Tabs disabled (default)
Delete from tree view closes corresponding file tab without error (check JS console)	✅	✅
Open Atom, create new file, save it. Deleting file outside Atom follows setting.	✅	✅
Open Atom, open existing file. Deleting outside Atom follows setting.	✅	✅
Open Atom project with existing files already open. Deleting outside Atom follows setting.	✅	✅
Open Atom project with an unsaved file preserved. Save it. Deleting outside Atom follows setting.	✅	✅
Open Atom, create new file, save it. Modify it without saving. Deleting file outside Atom keeps buffer open.	✅	✅
Open Atom, open existing file. Modify it without saving. Deleting file outside Atom keeps buffer open.	✅	✅
Open Atom project with existing files already open. Modify it without saving. Deleting file outside Atom keeps buffer open.	✅	✅
Open Atom project with an unsaved file preserved. Save it. Modify it without saving. Deleting file outside Atom keeps buffer open.	✅	✅

Linux(Centos)

	Close Deleted File Tabs enabled	Close Deleted File Tabs disabled (default)
Delete from tree view closes corresponding file tab without error (check JS console)	✅	✅
Open Atom, create new file, save it. Deleting file outside Atom follows setting.	✅	✅
Open Atom, open existing file. Deleting outside Atom follows setting.	✅	✅
Open Atom project with existing files already open. Deleting outside Atom follows setting.	✅	✅
Open Atom project with an unsaved file preserved. Save it. Deleting outside Atom follows setting.	✅	✅
Open Atom, create new file, save it. Modify it without saving. Deleting file outside Atom keeps buffer open.	✅	✅
Open Atom, open existing file. Modify it without saving. Deleting file outside Atom keeps buffer open.	✅	✅
Open Atom project with existing files already open. Modify it without saving. Deleting file outside Atom keeps buffer open.	✅	✅
Open Atom project with an unsaved file preserved. Save it. Modify it without saving. Deleting file outside Atom keeps buffer open.	✅	✅

[iolsen]

For the last item and the scenario Open Atom project with an unsaved file preserved. Save it. Deleting outside Atom follows setting., I can repro the issue. the other scenarios I'm seeing the file as marked as modify after deleting.

I see this, too. I'll investigate.

Another issue I saw was:
...
This could probably be a completely different issue. In which case, I can create a issue for this.

Please do. Sounds orthogonal to this one.

[iolsen]

I'm able to reproduce the issue @adamreisnz reported in the current stable, so I've logged atom/text-buffer#198 and am closing this.

This is set to ship in 1.15.

[Anthropic]

Thank you so very much @iolsen for all your work on this and @ungb @adamreisnz for helping to test it, thank you, you have made my day :)

[Anthropic]

@iolsen when you say 1.15 does that include 1.15.0-beta1?

When I switched branch in hg (mercurial) the file name still changed from
network-controller.js to network-controller.js-949cd2b1

Does that mean it is unrelated and still needs fixing or is there a flag I have missed in relation to the change?

[ungb]

Hey @Anthropic, Where do you see the file name changed? in the tab or tree-view?

I don't see this behavior. I installed hg(mercurial) and ran hg init. I open the project on atom-beta, deleted the file on one branch and changed branches, the file is removed when I check out the branch that has it deleted, but the tab stays(as expected).

[Anthropic]

In the tab only. Well in the tree view if I hit save obviously, but if I don't then only the tab.

[Anthropic]

Oh the file has to be in both revisions but changed

[Anthropic]

@iolsen @ungb ProjectTracking folder is my Mercurial repo that got updated to cause the file name to change in the editor. The file was available in both revisions. The annoying part is that even using save-as it doesn't open the same folder where the file was so it takes a while to line them back up again if there are any unsaved changes. I had this happen with over 20 open files and had no idea which had unsaved changes so I had to save all of them one by one just in case.

[Anthropic]

@iolsen @ungb I just found this also happens to me if I make a change in a file and then go into tortoisehg and revert the change, the file immediately gets the postfix appended to its name.

[ungb]

Hey @Anthropic, Thanks so much for all your feedback and reports of issues you are seeing. We definitely want to take a look at the issues you are seeing and make sure to fix them. Since this issue is closed, can you create another issue with repro steps the issues you are seeing above? It would help us prioritize and get the issue fixed faster.

[Anthropic]

@ungb I thought the same thing, I wrote one and then had to rush to lunch before sending, added it now #416 :)