Created attachment 2139 [details]
Patch to enable IMAP undelete

This patch adds the possibility to undelete IMAP messages.

1. To start out with the obvious: with an IMAP server, message deletion is a two-step process: first the "\Deleted" flag is set on the message(s), next an "expunge" command removes all messages with that flag.

This means that, in between, it is possible to "undelete" the message, simply by removing that flag again. Many MUA's have that functionality already.

The code to toggle the IMAP flag is already present in Claws Mail (imap.c), but it can't be used because the GUI ignores a delete command for a message that is already deleted.

The attached patch makes that mechanism available through the GUI: successive "delete" operations on the same message will now toggle the flag each time.


2. Of course, this will only work if "execute immediate" is not activated, otherwise the message will have been expunged already. 

One could say that, in that case, the user wouldn't be able to invoke the "undelete" command on it anyway, so we need not care about it, but I added a short test anyway.

Another prerequisite for an undelete is that the message lives in an IMAP folder.

The patch tests for these conditions, and simply ignores a second "delete" command if the message is already deleted and the requested "undelete" is not possible - exactly as before.


3. Now, if the above conditions are met and therefore a delete can indeed be undone later, it is no longer needed nor desirable to ask for confirmation first.

Of course, confirmation is still needed for irreversible deletes, i.e. for messages that are not in an IMAP folder etc.

The patch makes the distinction and will not ask for confirmation if the action is reversible.


4. As before, a "delete" operation works also when multiple messages are selected. It just becomes a "multi-delete" (as before), or a "multi-undelete" if all the selected messages are already flagged for deletion.

The question is what to do when the user selects a mix of "deleted" and "not yet deleted" messages. If we allow that, the code would not have any problem with it, the flags would simply be toggled for all of them. 

Clearly, this would lead to user surprises and is therefore not desirable. The patch will simply refuse an (un)delete operation in that case. Instead, it pops up an error message and stops processing the request.


5. What the patch does not (yet?) do is change the wording of menu items. They continue to say "Delete...", even when the message is already deleted and they should really say "Undelete" (note: without the dots!). 

And In the cosmetics department: if the delete can be undone, the menu item should not have any dots after the "Delete" either (because they promise a confirmation dialog that won't come).


6. I didn't think a new "enable_imap_undelete" preference was needed here.

But it is easy enough to add one to the patch if so desired.


7. And who knows, some day this "undelete" facility might become a building block for a "super-duper-doitall undo button", as requested more than ten years ago in bug 1972.