New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide option to allow keeping open deleted tabs #306

Closed
vjpr opened this Issue Apr 17, 2016 · 45 comments

Comments

Projects
None yet
@vjpr

vjpr commented Apr 17, 2016

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

This comment has been minimized.

Show comment
Hide comment
@jonathankoren

jonathankoren May 7, 2016

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.

jonathankoren commented May 7, 2016

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

This comment has been minimized.

Show comment
Hide comment
@lemire

lemire May 7, 2016

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 commented May 7, 2016

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

This comment has been minimized.

Show comment
Hide comment
@lemire

lemire May 7, 2016

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.

lemire commented May 7, 2016

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.

@lee-dohm lee-dohm added the enhancement label May 7, 2016

@Anthropic

This comment has been minimized.

Show comment
Hide comment
@Anthropic

Anthropic Jul 20, 2016

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.

Anthropic commented Jul 20, 2016

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

This comment has been minimized.

Show comment
Hide comment
@awkaiser

awkaiser Sep 13, 2016

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.

awkaiser commented Sep 13, 2016

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

This comment has been minimized.

Show comment
Hide comment
@lemire

lemire Sep 15, 2016

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.

lemire commented Sep 15, 2016

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

This comment has been minimized.

Show comment
Hide comment
@adamreisnz

adamreisnz Sep 15, 2016

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?

adamreisnz commented Sep 15, 2016

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

This comment has been minimized.

Show comment
Hide comment
@narayanpai

narayanpai Oct 7, 2016

@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

narayanpai commented Oct 7, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@Anthropic

Anthropic Oct 9, 2016

@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?

Anthropic commented Oct 9, 2016

@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?

@50Wliu

This comment has been minimized.

Show comment
Hide comment
@50Wliu
Member

50Wliu commented Oct 9, 2016

/cc @iolsen, @mnquintana

@iolsen iolsen added bug and removed enhancement labels Oct 9, 2016

@iolsen

This comment has been minimized.

Show comment
Hide comment
@iolsen

iolsen Oct 9, 2016

Contributor

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

Contributor

iolsen commented Oct 9, 2016

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

@Anthropic

This comment has been minimized.

Show comment
Hide comment
@Anthropic

Anthropic Oct 9, 2016

@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 commented Oct 9, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@Anthropic

Anthropic Oct 21, 2016

@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?

Anthropic commented Oct 21, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@iolsen

iolsen Oct 21, 2016

Contributor

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

Contributor

iolsen commented Oct 21, 2016

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

@awkaiser

This comment has been minimized.

Show comment
Hide comment
@awkaiser

awkaiser Dec 29, 2016

@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! 🎆

awkaiser commented Dec 29, 2016

@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! 🎆

@iolsen

This comment has been minimized.

Show comment
Hide comment
@iolsen

iolsen Jan 25, 2017

Contributor

@ungb this will be on master in a few minutes. I could use your help testing as follows:

Mac

Close Deleted File Tabs enabled Close Deleted File Tabs disabled (default)
Delete from tree view closes corresponding file tab without error
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.

Windows

Close Deleted File Tabs enabled Close Deleted File Tabs disabled (default)
Delete from tree view closes corresponding file tab without error
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.

Linux

Close Deleted File Tabs enabled Close Deleted File Tabs disabled (default)
Delete from tree view closes corresponding file tab without error
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.
Contributor

iolsen commented Jan 25, 2017

@ungb this will be on master in a few minutes. I could use your help testing as follows:

Mac

Close Deleted File Tabs enabled Close Deleted File Tabs disabled (default)
Delete from tree view closes corresponding file tab without error
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.

Windows

Close Deleted File Tabs enabled Close Deleted File Tabs disabled (default)
Delete from tree view closes corresponding file tab without error
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.

Linux

Close Deleted File Tabs enabled Close Deleted File Tabs disabled (default)
Delete from tree view closes corresponding file tab without error
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.
@adamreisnz

This comment has been minimized.

Show comment
Hide comment
@adamreisnz

adamreisnz Jan 25, 2017

@iolsen I'll be happy to test the mac case if you want

adamreisnz commented Jan 25, 2017

@iolsen I'll be happy to test the mac case if you want

@iolsen

This comment has been minimized.

Show comment
Hide comment
@iolsen

iolsen Jan 25, 2017

Contributor

@iolsen I'll be happy to test the mac case if you want

@adamreisnz great! Looks like builds are pretty backed up so my "in a few minutes" estimate above was off. I'll follow up here when it's all on master.

Contributor

iolsen commented Jan 25, 2017

@iolsen I'll be happy to test the mac case if you want

@adamreisnz great! Looks like builds are pretty backed up so my "in a few minutes" estimate above was off. I'll follow up here when it's all on master.

@iolsen

This comment has been minimized.

Show comment
Hide comment
@iolsen

iolsen Jan 26, 2017

Contributor

@ungb @adamreisnz this is good to go on master now.

Contributor

iolsen commented Jan 26, 2017

@ungb @adamreisnz this is good to go on master now.

@ungb

This comment has been minimized.

Show comment
Hide comment
@ungb

ungb Jan 26, 2017

thanks @adamreisnz, I'll take a look on windows and linux

ungb commented Jan 26, 2017

thanks @adamreisnz, I'll take a look on windows and linux

@adamreisnz

This comment has been minimized.

Show comment
Hide comment
@adamreisnz

adamreisnz Jan 26, 2017

@iolsen building the new version now

adamreisnz commented Jan 26, 2017

@iolsen building the new version now

@ungb

This comment has been minimized.

Show comment
Hide comment
@ungb

ungb Jan 26, 2017

From my test cases. it seems linux isn't working correctly. I tried on Centos 7.3.

See test cases and results:

Windows

Close Deleted File Tabs enabled Close Deleted File Tabs disabled (default) Works as expected?
Delete from tree view closes corresponding file tab without error Closes tab(Expected), No error Closes tab(Expected), No error Yes
Open Atom, create new file, save it. Deleting file outside Atom follows setting. Closes tab File is renamed to untitled, tab and file content still exist Yes
Open Atom, open existing file. Deleting outside Atom follows setting. Closes tab File is renamed to untitled, tab and file content still exist Yes
Open Atom project with existing files already open. Deleting outside Atom follows setting. Closes tab File is renamed to untitled, tab and file content still exist Yes
Open Atom project with an unsaved file preserved. Save it. Deleting outside Atom follows setting. Closes tab File is renamed back to untitled, tab and file content still exist Yes

Linux

Close Deleted File Tabs enabled Close Deleted File Tabs disabled (default) Works as expected?
Delete from tree view closes corresponding file tab without error Closes tab(Expected), No error Closes tab(Expected), No error Yes
Open Atom, create new file, save it. Deleting file outside Atom follows setting. File name is the same. Tab exist, file content still exist File name is the same. Tab exist, file content still exist No, When Closed Deleted Files Tab is checked, should remove the tab but it still exist
Open Atom, open existing file. Deleting outside Atom follows setting. File name is the same. Tab exist, file content still exist File name is the same. Tab exist, file content still exist No, When Closed Deleted Files Tab is checked, should remove the tab but it still exist
Open Atom project with existing files already open. Deleting outside Atom follows setting. File name is the same. Tab exist, file content still exist File name is the same. Tab exist, file content still exist No, When Closed Deleted Files Tab is checked, should remove the tab but it still exist
Open Atom project with an unsaved file preserved. Save it. Deleting outside Atom follows setting. Closes tab File is renamed to untitled, file content is deleted No, when Closed Deleted Files Tab is disabled, file content is deleted

Here's a gif if the scenario on linux when Closed Deleted Files Tab is not checked: Open Atom project with an unsaved file preserved. Save it. Deleting outside Atom follows setting.

bug

ungb commented Jan 26, 2017

From my test cases. it seems linux isn't working correctly. I tried on Centos 7.3.

See test cases and results:

Windows

Close Deleted File Tabs enabled Close Deleted File Tabs disabled (default) Works as expected?
Delete from tree view closes corresponding file tab without error Closes tab(Expected), No error Closes tab(Expected), No error Yes
Open Atom, create new file, save it. Deleting file outside Atom follows setting. Closes tab File is renamed to untitled, tab and file content still exist Yes
Open Atom, open existing file. Deleting outside Atom follows setting. Closes tab File is renamed to untitled, tab and file content still exist Yes
Open Atom project with existing files already open. Deleting outside Atom follows setting. Closes tab File is renamed to untitled, tab and file content still exist Yes
Open Atom project with an unsaved file preserved. Save it. Deleting outside Atom follows setting. Closes tab File is renamed back to untitled, tab and file content still exist Yes

Linux

Close Deleted File Tabs enabled Close Deleted File Tabs disabled (default) Works as expected?
Delete from tree view closes corresponding file tab without error Closes tab(Expected), No error Closes tab(Expected), No error Yes
Open Atom, create new file, save it. Deleting file outside Atom follows setting. File name is the same. Tab exist, file content still exist File name is the same. Tab exist, file content still exist No, When Closed Deleted Files Tab is checked, should remove the tab but it still exist
Open Atom, open existing file. Deleting outside Atom follows setting. File name is the same. Tab exist, file content still exist File name is the same. Tab exist, file content still exist No, When Closed Deleted Files Tab is checked, should remove the tab but it still exist
Open Atom project with existing files already open. Deleting outside Atom follows setting. File name is the same. Tab exist, file content still exist File name is the same. Tab exist, file content still exist No, When Closed Deleted Files Tab is checked, should remove the tab but it still exist
Open Atom project with an unsaved file preserved. Save it. Deleting outside Atom follows setting. Closes tab File is renamed to untitled, file content is deleted No, when Closed Deleted Files Tab is disabled, file content is deleted

Here's a gif if the scenario on linux when Closed Deleted Files Tab is not checked: Open Atom project with an unsaved file preserved. Save it. Deleting outside Atom follows setting.

bug

@ungb

This comment has been minimized.

Show comment
Hide comment
@ungb

ungb Jan 26, 2017

I tried some testing on sublime text on mac and saw that when you delete the file outside of sublime text the file and content remains. The only thing that changes is the file looks modified. Similar to how it is behaving in linux.

ungb commented Jan 26, 2017

I tried some testing on sublime text on mac and saw that when you delete the file outside of sublime text the file and content remains. The only thing that changes is the file looks modified. Similar to how it is behaving in linux.

@50Wliu

This comment has been minimized.

Show comment
Hide comment
@50Wliu

50Wliu Jan 26, 2017

Member

File is renamed to untitled, tab and file content still exist

I 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.

Member

50Wliu commented Jan 26, 2017

File is renamed to untitled, tab and file content still exist

I 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.

@Anthropic

This comment has been minimized.

Show comment
Hide comment
@Anthropic

Anthropic Jan 26, 2017

And Sublime

Anthropic commented Jan 26, 2017

And Sublime

@iolsen

This comment has been minimized.

Show comment
Hide comment
@iolsen

iolsen Jan 26, 2017

Contributor

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.

Contributor

iolsen commented Jan 26, 2017

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

This comment has been minimized.

Show comment
Hide comment
@ungb

ungb Jan 27, 2017

@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

ungb commented Jan 27, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@adamreisnz

adamreisnz Jan 27, 2017

@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.

adamreisnz commented Jan 27, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@iolsen

iolsen Jan 27, 2017

Contributor

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.

Contributor

iolsen commented Jan 27, 2017

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

This comment has been minimized.

Show comment
Hide comment
@adamreisnz

adamreisnz Jan 27, 2017

Cool, no worries. Glad I could help.

adamreisnz commented Jan 27, 2017

Cool, no worries. Glad I could help.

@iolsen

This comment has been minimized.

Show comment
Hide comment
@iolsen

iolsen Feb 1, 2017

Contributor

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.
Contributor

iolsen commented Feb 1, 2017

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

This comment has been minimized.

Show comment
Hide comment
@adamreisnz

adamreisnz Feb 2, 2017

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

adamreisnz commented Feb 2, 2017

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

This comment has been minimized.

Show comment
Hide comment
@ungb

ungb Feb 2, 2017

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.:

working

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

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

ungb commented Feb 2, 2017

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.:

working

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

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

@ungb

This comment has been minimized.

Show comment
Hide comment
@ungb

ungb Feb 2, 2017

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.

ungb commented Feb 2, 2017

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

This comment has been minimized.

Show comment
Hide comment
@iolsen

iolsen Feb 2, 2017

Contributor

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.

Contributor

iolsen commented Feb 2, 2017

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

This comment has been minimized.

Show comment
Hide comment
@iolsen

iolsen Feb 2, 2017

Contributor

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.

Contributor

iolsen commented Feb 2, 2017

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.

@iolsen iolsen closed this Feb 2, 2017

@Anthropic

This comment has been minimized.

Show comment
Hide comment
@Anthropic

Anthropic Feb 2, 2017

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 commented Feb 2, 2017

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

This comment has been minimized.

Show comment
Hide comment
@Anthropic

Anthropic Feb 10, 2017

@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?

Anthropic commented Feb 10, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@ungb

ungb Feb 10, 2017

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).

ungb commented Feb 10, 2017

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

This comment has been minimized.

Show comment
Hide comment
@Anthropic

Anthropic Feb 10, 2017

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

Anthropic commented Feb 10, 2017

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

@Anthropic

This comment has been minimized.

Show comment
Hide comment
@Anthropic

Anthropic Feb 10, 2017

Oh the file has to be in both revisions but changed

Anthropic commented Feb 10, 2017

Oh the file has to be in both revisions but changed

@Anthropic

This comment has been minimized.

Show comment
Hide comment
@Anthropic

Anthropic Feb 13, 2017

@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.
atom-error

Anthropic commented Feb 13, 2017

@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.
atom-error

@Anthropic

This comment has been minimized.

Show comment
Hide comment
@Anthropic

Anthropic Feb 23, 2017

@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.

Anthropic commented Feb 23, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@ungb

ungb Feb 23, 2017

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.

ungb commented Feb 23, 2017

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

This comment has been minimized.

Show comment
Hide comment
@Anthropic

Anthropic Feb 23, 2017

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

Anthropic commented Feb 23, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment