Tab of deleted file should be closed

[adamreisnz]

When you delete a file, if it was open in a tab I think the tab should be closed.

What happens now, is that after deleting a file from within tree view, the tab remains open with the file being in trash. Then when you want to close the window, you get a confirmation screen asking you if you want to save the file or not. This is pretty annoying and seems redundant. Deleting a file already comes with it's own confirmation dialog.

If this is an issue for atom/tree-view let me know and I'll re-post there.

[flynfish]

agreed, I also run into this a lot

[Haraldson]

And then when emptying trash, you usually get one of those annoying red error warning popups. Hoping for a fix for this one as well.

[astorije]

Agreed when you delete the file from the file tree, but when the file is edited or removed from outside of Atom, it's nice to keep it around (or to keep it untouched in the case of edited files).
It works that way in Sublime Text (maybe it already works like this with Atom, I haven't checked), and it saved my a*s a few times when the file I didn't save the file I was editing and it changed on the file system (typically, what git does).

[rlam3]

+10000000

[harai]

+1

[sterjakov]

+11111

[dobozysaurus]

+1

[jonniedarko]

+1

[icem]

👍

[janmarek]

I hate how Atom team just ignores these easy to fix UI problems.

[mwinters0]

@janmarek PRs are always welcome

[janmarek]

@MikeSchuette How can you be so sure? We have no reaction from the core team here. They should let us know they agree it is a good idea. Nobody wants to waste their time for nothing.

[winstliu]

@janmarek The atom label means that the Atom team is interested in bringing this functionality into core, so yes, a PR is welcome. You could also have asked if a PR would be welcome (they almost always are) instead of jumping straight to conclusions.

[lee-dohm]

@acontreras89 can you take a look at this?

[lee-dohm]

Here's what I did to reproduce this:

1. Launch Atom in a project directory
2. Open a new file using Cmd+N
3. Save the file as test.txt by pressing Cmd+S
4. Find the file in the tree-view, right-click it and select "Delete"
5. Click the "Move to Trash" button in the dialog that pops up

Expected: Both the file to disappear from the tree-view and the tab to close
Actual: File disappears from tree-view but the tab does not close

Reproduced using Atom v1.7.0-dev-dc987b6 on Mac OS X 10.11.3.

[acontreras89]

I cannot reproduce this on Linux, although I'm positive I've had this very issue while in the office (with OS X.) If no one takes the challenge, I'll try to take another look from there 💪

[anderoonies]

looks like this is a result of files on OS X not being "deleted" but rather moved—i cooked up a primitive solution subscribing to rename events, i can create a PR tomorrow and see if it's on the right track

[adamreisnz]

Yes, if the files are "moved" to the trash, you can happily keep editing them from within the trash, as it's just a hidden location, but accessible like any other.

Is this different on Windows?

[anderoonies]

it looks like this issue goes further up into the implementation of File in node-pathwatcher—the 'did-delete' event is never emitted when a file is moved to the trash.

[adamreisnz]

So I guess the question becomes if we should raise the issue there, or if Atom should check if a file has been moved to the trash, and trigger the delete event itself.

I'm inclined to think Atom should do this check, as moving a file to trash is not a file delete event, so node-pathwatcher will probably not want to change the behaviour.

Once I empty the trash, the tab does close by the way.

[Haraldson]

I’d say emitting a did-delete event upon moving a file to the trash would be the best fit to the whole Apple way of thinking. Only techies care about the distinction that it’s not technically deleted, but merely moved.

[adamreisnz]

True, but a lot of techies probably use that node package, and if it
suddenly starts emitting deleted events for moved files, that might upset
them :)

On Mon, Feb 15, 2016, 20:11 Hein Haraldson Berg [email protected]
wrote:

I’d say emitting a did-delete event upon moving a file to the trash would
be the best fit to the whole Apple way of thinking. Only techies care about
the distinction that it’s not technically deleted, but merely moved.

—
Reply to this email directly or view it on GitHub
#160 (comment).

[acontreras89]

the 'did-delete' event is never emitted when a file is moved to the trash.

That's what I suspected.

I'd give a penny for @kevinsawicki's thoughts on whether node-pathwatcher should be emitting did-delete events for files moved to the trash in OSX.

[lee-dohm]

I haven't looked at node-pathwatcher, but I assume it emits an event on filename or path changes? What if, on OS X and when moved to .Trash, we respond to those by closing the tab?

[adamreisnz]

@lee-dohm yes that's what I thought would make the most sense

[acontreras89]

I would agree with you, but I thought since node-pathwatcher is a module of atom's it was worth asking what the best approach would be.

On the other hand, maybe this should be solved somewhere else and not the tabs package.
Even if the event will not be emitted by node-pathwatcher, maybe atom's core should be in charge of triggering it (if everyone is supposed to act as if the file were deleted, e.g. atom/find-and-replace#634.)
Or tree-view could also take care of this after deleting the file.

[acontreras89]

atom/node-pathwatcher#106 has been merged, which may solve this problem. @adambuczynski can you ensure this is working properly with the latest version of node-pathwatcher?

[jonniedarko]

👍

On Mon, Mar 7, 2016, 9:48 AM Aaron Contreras [email protected]
wrote:

atom/node-pathwatcher#106
atom/node-pathwatcher#106 has been merged,
which may solve this problem. @adambuczynski
https://github.com/adambuczynski can you ensure this is working
properly with the latest version of node-pathwatcher?

—
Reply to this email directly or view it on GitHub
#160 (comment).

[adamreisnz]

@acontreras89 I'll gladly check all the issues, yes. Is this going to be released with Atom 1.6.0-beta8?

[adamreisnz]

@acontreras89 never mind, I've built the latest Atom myself.

I can confirm this is now fixed in 1.7.0-dev-42c6d5c
Great job, thank you 👍

[lemire]

I don't think that this is an ideal change as implemented. The orphan buffer should remain so that the users can save it elsewhere if needed.

[adamreisnz]

@lemire In the majority of use cases when someone deletes a file, presumable they don't want it or it's contents anymore. Having the previous behaviour was creating inconsistencies between Atom in windows and mac due to differences between file events when moving a file to trash. It was extremely annoying for the majority of use cases where you'd just want to get rid of a file, as it was creating orphaned tabs in the editor and unnecessary confirmation dialogs.

If you have edited the file before deleting it and need to save the changes, you should probably do so before you trash the file in the first place. However, I assume a check could be put in place to preserve the tab if it has any unsaved changes.

@acontreras89 what are your thoughts, is it possible to include such a check?

[lee-dohm]

I just tested this using Atom v1.9.0-dev-c31ade9 on Mac OS X 10.11.4. If the tab is marked dirty, in other words the file in memory has been changed relative to the version on disk, then the tab is not closed when the file is deleted. The tab is not closed both when the file is deleted via Atom or via an external process (tested with rm filename in a separate terminal window).

[lemire]

@adambuczynski I think only Atom behaves this way.

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.

[adamreisnz]

@lemire if you have a better solution that addresses both sides of the story, then I think the Atom team would love to hear it ;)

[lee-dohm]

@lemire #306 is open to add an option for the behavior you specify. You may want to subscribe there for updates.

[lemire]

@adambuczynski @lee-dohm

I'll take the discussion there, but considering that every single IDE, word processor or text editor that I have tried does not follow this new pattern... I am arguing that this new behavior is likely to take users by surprise.

[adamreisnz]

@lemire I appreciate your use case, but I merely reported this issue here because deleting an unedited file from within Atom which had it's tab open caused you to have to jump through 4 different hoops:

1. Right click on file in tree view and select delete
2. Confirm you want to delete
3. Close the tab of the deleted file manually
4. Confirm once again that you want to close the tab, because the file was marked as edited due to the deletion

I don't know of any other IDE or text editor which had the same convoluted process with a double confirmation when deleting a file from within the editor, so I would say this behaviour was undesireable.

I agree however that files being deleted externally are a different use case and should probably be handled differently, as @astorije also pointed out above.

[lemire]

@adambuczynski

I totally agree that if you delete the file within Atom then there should be one confirmation dialog and then the file and the buffer should be gone.

I am not arguing for a total reversal of this feature, but rather for a partial reversal or an adjustment so that the behavior is in line with other editors.

[northamerican]

Automatically closing 'deleted' files are a hassle when switching branches. Sometime I want to briefly checkout a branch where my unstaged files don't exist. When I return to my branch with unstaged new files, I'm forced to reopen them in Atom. At least make it an option.

[astorije]

What version are you using, @northamerican? I am working with git on many repos and branches every day and I don't recall noticing this.

[adamreisnz]

@astorije this does in fact happen to me as well. For example just now I switched to an older branch (where certain files that I had been working on hadn't been created yet), and Atom does close those tabs.

So when I switched back, I had to reopen those files again manually. This is with Atom 1.12.0-dev-059dbba.

Not sure how to resolve this issue while still closing tabs of actually deleted files. Maybe a short lived history of closed tabs due to file deletes can be kept in memory, and if the files are restored within say 5 minutes, the tabs are reopened automatically?

[northamerican]

i created an issue for this: atom/atom#12613

[FezVrasta]

I have a similar problem but when I rename a folder.

Example:

1. have a folder with few files inside
2. open those files
3. rename the folder
4. the tabs of these files remain open and point to the old folder name

This makes me edit the old files instead of the new ones and when I save, I re-create the old folder, actually duplicating the file... This is very annoying.

[Ben3eeE]

@FezVrasta There is an open issue for this here #12

[FezVrasta]

That one seems just about the tooltip? My problem is with the actual behaviour.

[jolsen71]

I believe the tooltip issue in #12 and your reported issue are both symptom of the same underlying problem, which is why @Ben3eeE linked to #12. It seems like Atom is not aware of the rename so the file location associated with the buffer is not updated, therefore the tooltip shows the original path and when you hit save it saves to the original path. So, if Atom is able to be made aware of the rename and updates the buffer's file location, then the tooltip path and where the next save is applied will both be correct.

[Ben3eeE]

Exactly. Since the steps to reproduce are the same I am thinking it could be the same underlying problem. @FezVrasta Can you post your finding as a comment in that issue and we will take a look, thanks.

[FezVrasta]

I see, I guess the title should be updated to make it clear that it's a wider problem (not just a wrong label).