From: Mark Walters <markwalters1009@gmail.com>
To: notmuch@notmuchmail.org
Subject: Emacs: postponing messages
User-Agent: Notmuch/0.22~rc1+4~g410fd6d (http://notmuchmail.org) Emacs/24.4.1
 (x86_64-pc-linux-gnu)
Date: Thu, 02 Jun 2016 19:21:44 +0100
Message-ID: <87mvn330zr.fsf@qmul.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list


Dear All

There was some discussion on irc yesterday about a better way of
postponing message when using the emacs frontend. I think getting a
moderately nice interface should be quite easy (see below) but there are
some corner cases on what *should* happen that I would like to resolve
before trying to implement anything.

My broad idea for postpone is to take the partial message, use notmuch
insert to put it in the database with a "postponed" tag, and then on
resume fetch the raw message and go into notmuch-message-mode, and also
either add a deleted tag to the resumed message, or better actually
delete the resumed message. Finally, we would add postponed to the
excluded tags list, so that postponed messages only show up when
searched for.

Now the main difficulty I see is what to do with attachments.

If we just leave the mml #part markers in the message then the file
might have disappeared by the time we resume (or could even be a
different file). This would be a particular problem if people attach
files that are in /tmp say.

Further the way rfc822 forwarding works (ie the default forwarding in
notmuch/emacs) is to put each attachment of the message that is being
forwarded into its own emacs buffer, and include these buffers via the
mml markers. These buffers would all disappear if the user restarts
emacs between postponing and resume.

An alternative would be to attach the attachments with the postponed
message. This is probably doable by writing the message (as if being
fcc'd) to notmuch insert, and then using the mime-to-mml function to
reverse the process. The downside here is that now the attached file is
not the current file in the filesystem when you send -- ie its different
from the normal case.

Any thoughts or comments very gratefully received!

Best wishes

Mark