Fix blender save#590
Conversation
0xpr03
left a comment
0xpr03
left a comment
There was a problem hiding this comment.
I think we will need way more documentation to keep this usable in the future
|
|
||
| events_expired.push(event); | ||
| } else { | ||
| self.queues.get_mut(&path).unwrap().events.push_front(event); |
There was a problem hiding this comment.
same here for unwrap stuff - want to avoid crashing and rather report an error
dfaust
force-pushed
the
fix-blender-save
branch
from
b110f0e to
3fb1c37
Compare
Agreed. I will add more comments as I work on it. |
|
We can merge this for now, if you want. I just would like to document this, because I fear we will otherwise have a ton of regressions in the future. |
|
Then let's not merge it for now. I will document it better and try to fix the original issue. While the PR does improve the behavior of the debouncer, it doesn't actually fix the blender issue. |
dfaust
force-pushed
the
fix-blender-save
branch
from
3fb1c37 to
b9f9512
Compare
| ## unreleased | ||
|
|
||
| - CHANGE: emit `remove` events even if a file was created and then removed (because macOS repeats the "create" event) [#900] **breaking** | ||
| - FIX: ordering of debounced events when multiple files are modified and renamed (eg. during a safe save performed by Blender) [#590] |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
There was a problem hiding this comment.
Nope. I'm specifically talking about the "safe" saving process where a new file is written first and then moved to the original location.
3 participants
The debouncer is getting increasingly complicated. It took me a few tries to design this change as defensively as possible. I hope it doesn't break anything.
This PR is based on #569.