Add basic undo in project panel

[marcocondrache]

Initial part for #5039

Continues work from #45008. The author is no longer assigned to the issue, so I’m assuming it’s unclaimed. Please close this if that’s not correct.

• Undo rename
• Undo move
• Undo paste
• Undo drag
• Enough tests

Release Notes:

• N/A

[cla-bot]

We require contributors to sign our Contributor License Agreement, and we don't have @HactarCE on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'.

[HactarCE]

I no longer work at Zed, but I'm glad someone picked this up. Thank you so much for continuing this!

[HactarCE]

@cla-bot check

[cla-bot]

The cla-bot has been summoned, and re-checked this pull request!

[dinocosta]

Hey @marcocondrache 👋

Thanks for opening this. I was looking at #5039 last week to pick it up and see if we can ship it, so it’s great to see you continuing the work from #45008 !

I paired briefly with @cole-miller today, and we’re planning to update Byron/trash-rs to centralize all trashing and restoring logic there. That crate already provides restoration logic, and both Byron/trash-rs#109 and Byron/trash-rs#128 explore returning the actual item that was trashed, for both Linux and macOS, so that it can be restored. With those changes, it seems we’d only be missing restoration support for macOS as well as returning trashed items on Windows.

If that goes well, we may update these PR changes accordingly, assuming you’re comfortable with that. Let me know if you’re up for some pairing time 🙂

[marcocondrache]

Hey @dinocosta, thanks for checking this - I had exactly the same idea.

Instead of copying to a temporary folder like in #45008, we can reuse the OS trash and avoid doing the work twice. The current state of the PR already does this (at least on macOS), and I’ve been exploring how to implement it on Linux and Windows as well.

I looked at trash-rs when starting the PR, but I didn’t really like the implementation. It requires passing around handles to trashed items, which gets inconvenient, especially for remote worktrees since they’d need proto serialization. I’m currently working on a separate trash crate that abstracts the platform implementation like trash-rs does and allows restoration by only knowing the old path (I can explain how this works).

I love pairing sessions, so we can arrange a meeting.

[dinocosta]

Hey @marcocondrache 👋

Thank you so much for continuing the work on this! I've had a chance to review the current state of these changes and leave some comments in the code, where appropriate.

Some feedback isn't particular to the file or code, so I'll leave it here instead:

• We'll probably need to think a little bit more on how we undo the ProjectPanelOperation::Batch operation. The current implementation seems to simply pop the operation off the stack and then attempts to undo all the operations within it. However, it seems that, if one of the operations within the batch fails to undo, we halt execution and silently "drop" the remaining operations. I wonder if we'll want to, at least, notify the user of which operations failed.
• We still need to explore how we're going to deal with conflicts. For example, right now, if I have a src/main.rs file and, through the Project Panel, rename it to src/bananas.rs but then, outside of Zed, create a new src/main.rs file, attempting to undo the rename will silently fail, while also popping the operation from the undo_stack. For the scope of this Pull Request, I believe we only need to care about displaying an error message to the user when undoing an operation fails, possibly with concrete information on what the operation was trying to do, for example, in the case shared above we'd likely want to tell the user that the rename failed because the target file already exists. In a future Pull Request, we might want to explore how to actually provide conflict resolution steps to the user, maybe something as simple as allowing the user to skip the operation or keeping track of the failed operations so we can retry, after the user manually resolves the conflict.
• Having an "Undo" option option to the right-click menu used in the project panel might also make it easier to discover that this feature exists.
  • Should be disable in case undo_stack.is_empty() is true
  • I might also, in the future, discuss with our design team if there's any icon/indicator/button we want to add for this, to make it easier for folks to know it exists
• I feel like maybe creating a new crates/project_panel/src/undo.rs module might be a good idea, so we can centralize all this undo/redo system logic and implementation there, especially since crates/project_panel/src/project_panel.rs is already ~6500 lines long.

Hope this helps! Let me know if you have any question or suggestion regarding any of the points or if there's something you'd prefer we pair on. Thanks! 🙂

[marcocondrache]

@dinocosta thanks a lot for reviewing this!

• I extracted the logic into undo.rs to make it easier to manage and reason about. I've got inspired by https://developer.apple.com/documentation/foundation/undomanager
• I looked at how VSCode handles conflicts during undo operations. It simply shows a toast notification with the raw error message, I think we can do something similar.
• I updated the revert logic for ProjectPanelOperation::Batch so it attempts to undo all operations and then collects any errors that occur. We still need to decide how we want to surface or handle errors in this particular case.

[dinocosta]

Hey @marcocondrache ! 👋

Thank you so much for tackling the provided feedback, and sorry for the late reply! I ended up pushing some changes, should be pretty easy for you to review what I changed based on each commit's message but here's a quick overview:

• Update the revert implementation for Create in order to actually trash and not delete the file
• Implemented error notifications when undoing a project panel operation fails
• Refactored UndoManager::stack to use std::colllections::VecDeque instead of circular_buffer::CircularBuffer
  • Since Rust's standard library already provides a structure to implement a ring buffer, I though we could use that instead, only downside is that we need to be the ones ensuring that we respect the operations limit, but that seems okay
  • I believe this will also make it easier to implement redo support, as we could easily keep track of a cursor/index in the vector, such that, undoing an operation moves the decreases the cursor and redoing simply increases the cursor. Any new actions would simply be inserted at the current cursor position, discarding any operations that existed from the cursor to the stack's end

Feel free to take a look at the changes! I'm also organizing next steps and will update you as soon as possible 😀