I've been working toward improving Pulsar's handling of deleted files in order to reduce the number of unnecessary buffer-management tasks that need to be done when (e.g.) switching Git branches.
The work is going decently and is tracked in pulsar-edit/pulsar#1588. But I've run into quite the snag.
Here's the scenario:
- You open a buffer that has a file on disk (let's say
foo.txt).
- While that buffer is open in your workspace, an external program deletes
foo.txt.
- We keep it open in your workspace (depending on your configuration) but mark the file as deleted in the tab so that you'll understand why you may not see it in your tree view.
- A few minutes later, an external program restores
foo.txt. The contents may or may not be the same as they once were.
The core problem is that we do not detect this “resurrection” and therefore cannot update either the buffer contents (if they have changed) or the “deleted” status on the tab. If you were to call TextEditor.isDeleted(), it would return false; but we do not currently have the ability to watch for the file's re-creation and trigger an event when that happens.
In the simple case, this is not a hard problem; we need only add some logic to pathwatcher. It typically watches the parent directory of a file (rather than the file itself) to detect when a certain file has changed, so we'd be able to do something like
let file = new File('nonexistent-path.txt');
file.onDidChange(() => console.log('changed!'));
// later…
fs.writeFileSync('nonexistent-path.txt`, 'some contents');
and have our handler get triggered.
But pathwatcher is a non-recursive file-watcher, so that only works in scenarios where the deleted file's parent directory still exists. We already only begrudgingly acknowledge the need for pathwatcher to exist in the first place; we're for damn sure not going to add recursive watching to it!
So one way to fix this would be to design an API around the idea that an external watcher (like the recursive watcher that is automatically set up when the user opens a project) could detect file creations, see if there are any associated text buffers in the workspace, and trigger a buffer reload to update its state.
I've been working toward improving Pulsar's handling of deleted files in order to reduce the number of unnecessary buffer-management tasks that need to be done when (e.g.) switching Git branches.
The work is going decently and is tracked in pulsar-edit/pulsar#1588. But I've run into quite the snag.
Here's the scenario:
foo.txt).foo.txt.foo.txt. The contents may or may not be the same as they once were.The core problem is that we do not detect this “resurrection” and therefore cannot update either the buffer contents (if they have changed) or the “deleted” status on the tab. If you were to call
TextEditor.isDeleted(), it would returnfalse; but we do not currently have the ability to watch for the file's re-creation and trigger an event when that happens.In the simple case, this is not a hard problem; we need only add some logic to
pathwatcher. It typically watches the parent directory of a file (rather than the file itself) to detect when a certain file has changed, so we'd be able to do something likeand have our handler get triggered.
But
pathwatcheris a non-recursive file-watcher, so that only works in scenarios where the deleted file's parent directory still exists. We already only begrudgingly acknowledge the need forpathwatcherto exist in the first place; we're for damn sure not going to add recursive watching to it!So one way to fix this would be to design an API around the idea that an external watcher (like the recursive watcher that is automatically set up when the user opens a project) could detect file creations, see if there are any associated text buffers in the workspace, and trigger a buffer reload to update its state.