Enhancement request: move to trash instead of removing

[FedericoStra]

Hello, very nice application, I discovered it today and already know that I'll use it for the rest of my life!

Just a little idea: would it be possible to add the option to move marked files to trash instead of permanently removing them? Probably something like https://crates.io/crates/trash might be useful. The command could be bound to Ctrl+t in the mark pane for instance.

In the weekend I might have time to try and propose a PR.

Edit: a few notes after a brief glance at the code, for my future self and others.

• In function AppState::dispatch_to_mark_pane add an arm Some(MarkMode::Trash) to the match.
• Implement AppState::trash_entry in addition to AppState::delete_entry, using https://crates.io/crates/trash.
• Add a Trash variant to the enum MarkMode.
• Add an arm Ctrl('r') => return Some(self.prepare_trashing()) to the match in MarkPane::process_events.
• Implement MarkPane::prepare_trashing in addition to MarkPane::prepare_deletion, which returns the MarkMode::Trash variant.

[Byron]

Hello, very nice application, I discovered it today and already know that I'll use it for the rest of my life!

If that isn't a wonderful compliment then I don't know what is :) - thank you, I am glad you like it as much as I do, being an avid user myself.

Just a little idea: would it be possible to add the option to move marked files to trash instead of permanently removing them? Probably something like https://crates.io/crates/trash might be useful. The command could be bound to Ctrl+t in the mark pane for instance.

Absolutely, I like using the an existing crate for that and binding it to Ctrl+t as well. A possible footgun to be aware of though is that dua will happily let you add child paths after their parent is already marked for deletion, causing it to try to delete a path which is already gone by then. This would make the trash crate fail, and I hope it's possible to see that the desired path didn't exist anymore to allow ignoring such failures.

Besides that, your suggestions on how to implement it seem sound, and I hope that's possible without duplicating too much of the logic which is the same in both cases except for the operation ultimately performed.

[Byron]

Fixed with v2.14.0