On Fri 2016-06-03 13:49:52 -0400, Mark Walters <markwalters1009@gmail.com> wrote:
> This is a new version of the WIP patch at
> id:1464915472-5669-1-git-send-email-markwalters1009@gmail.com
>
> So far it seems to deal with all cases that I have tried, and the
> CAVEATS list is rather smaller than before.
>
> The bindings are C-x C-s to save a draft (in notmuch-message-mode) C-c
> C-p to postpone a draft (ie save and exit buffer), and "e" to resume
> editing from either show or tree mode. You may want to add "draft" to
> your list of excluded tags to hide them unless you specifically search
> for them.

This is a really useful series, even with the caveats Mark lists.  i've
tested it and it behaves as expected for me.

A bit more discussion on the caveats:

> Each save saves a separate copy of the message. We hide these copies
> with the deleted tag but we don't actually delete them. Thus if you
> save several copies of message with large attachments you will use a
> lot of space.

This is a little bit weird, because it means that all these deleted
drafts show up in the thread view when viewing the thread from which the
message was composed.  Is there a reason to not actually delete older
drafts when "re-postponing" or sending?  We created the message
ourselves, so it seems like it's fair to delete it.

> If you use signing or encryption then I don't know what will happen: 
> I have not tested at all.  You might sign a partial message that you
> didn't mean too; you might expose plain text to someone.

I've just tested this for signing, and it's doing the thing i was afraid
it would do :/ When saving a draft marked as a message to be signed, the
message signature is made on the draft.  Even worse, restoring a saved
draft like this leaves the user editing the plaintext while the old
message signature is likely to be appended, which will result in broken
signatures :/

Maybe there's a way to temporarily inhibit the interpretation of all
#secure flags during draft saving (and propagate them through upon
resume)?  I think that would be advisable anyway -- if we ultimately
decide that we want to encrypt drafts, we don't want to encrypt them to
the actual recipients anyway; we only want encrypt-to-self, because we
want to avoid the situation where the person we're sending the message
to gets access to our drafts folder and reads our unfinished/unedited
compositions, so that would be a separate and distinct improvement.

> Finally, and this is not really a caveat, it *may* be possible to resume
> a previously sent message. At the moment I haven't tested this, and
> have made it so that emacs warns before allowing it.

I've tested it.  It's possible, and it even seems to work :) there are
weird interactions between things like DKIM and modified message-ids,
but i think the warning provided is sufficient to let people know that
if they're doing that sort of thing and something breaks, they get to
keep both pieces.  The biggest danger, i think, is in marking the
non-draft for deletion if a user goes ahead with restoring it.

          --dkg