Fixes #104 and subsequently atom/tabs#160, atom/find-and-replace#634, atom/fuzzy-finder#168.
The issue was that Move To Trash, which is how tree-view deletes items, was not being interpreted as a delete event by HandleWatcher.
This PR adds a check in HandleWatcher any time a rename event is emitted to see if it was a move to a .Trash dir. If it was, it emits a delete event in stead of a rename event to the PathWatcher.
A spec is included, but testing can also be done in any of the referenced packages by recreating the steps in the respective issues.
Some questions/room for improvement:
Is HandleWatcher low enough to be handling this or should it be done in pathwatcher_unix.cc?
Should the regular expression be more rigorous (checking process.env.HOME), or can it be assumed that any directory named /.Trash/ should behave as the system's trash?
I'm a bit nervous doing this, we should probably add a new event type for moving to trash. But I can't find any side effect for now, so let's merge this and see how it works.
Fixes #104 and subsequently atom/tabs#160, atom/find-and-replace#634, atom/fuzzy-finder#168. The issue was that
Move To Trash
, which is howtree-view
deletes items, was not being interpreted as adelete
event byHandleWatcher
. This PR adds a check inHandleWatcher
any time arename
event is emitted to see if it was a move to a.Trash
dir. If it was, it emits adelete
event in stead of arename
event to thePathWatcher
.A spec is included, but testing can also be done in any of the referenced packages by recreating the steps in the respective issues.
Some questions/room for improvement:
HandleWatcher
low enough to be handling this or should it be done inpathwatcher_unix.cc
?process.env.HOME
), or can it be assumed that any directory named/.Trash/
should behave as the system's trash?