Emacs: postponing messages

Daniel Kahn Gillmor dkg at fifthhorseman.net
Thu Jun 2 13:36:39 PDT 2016


On Thu 2016-06-02 14:21:44 -0400, Mark Walters wrote:
> 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.

I'd love to see this happen.  The terminology many other mail user
agents use for this workflow is often "draft" or "drafts" so we might do
well to adopt that term, instead of using "postpone", which i don't
think is as widely-used.

> 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.

I like this approach, and i don't think that the caveat you're
describing is a particuarly bad one, though it depends on how
mime-to-mml works.

I just tested it, and mime-to-mml actually produced something that was
not directly sendable in notmuch-message-mode, because it didn't include
the "--text follows this line--" break between headers and body :/  But
this is probably fixable ;)

However, mime-to-mml actually embedded the content of the included
sub-part upon reconstruction and the filename was only the leaf filename
(i'd included /home/dkg/tmp/test.txt, and in the reconstructed #part it
said filename="test.txt" nofile=yes)

Since this doesn't include the original path of the file (and it said
"nofile=yes"), then i don't think it's a problem.

One thing i should note is that if there's a message-id assigned during
saving of the draft, then we need to think carefully about how a draft
that gets saved multiple times gets indexed.  it'll have the same
message-id, which is good, but there will likely be multiple files
referencing it, each with different content.  ideally, there would only
be one copy indexed, and it would be the latest one.  Also, the
actually-sent mail should be indexed in preference over a previous
draft.

The above pieces would all be really great to have!  In addition, if
they were in place, it'd be good to have an variant notmuch-search view
that lists the recipients instead of the senders, so that i can do a
search for tag:draft and actually see who the messages were sent to,
instead of my own name (as the sender) on each item :)

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20160602/b7b37ac8/attachment.sig>


More information about the notmuch mailing list