unifying and automating draft ("postpone/resume") behavior [was: Re: notmuch "lost" email during power failure]

Daniel Kahn Gillmor dkg at fifthhorseman.net
Wed Nov 13 17:16:51 PST 2019


On Wed 2019-11-13 10:19:05 -0500, Antoine Beaupré wrote:
> Fundamentally, I think message-mode should treat emails the same way
> epg.el treats encrypted files: the data in the buffer isn't the same as
> the on-disk data, and there should be translation between the two. At
> the very least, the on-disk data could be a properly formed email
> message. If it's marked as needing encryption, then it should be
> encrypted.

i think it might be easier for notmuch-emacs to override message-mode
entirely, than to try to convince message-mode to do something so
radically different.

but i agree with you that it would be nice for the whole emacs MUA
ecosystem if they were more sensible there.

> Arguably, I haven't looked in details at how epg.el works: maybe it
> suffers from the same flaw. But from what I can tell, it simply bypasses
> the autosave functionality. If you have edit an ecrypted file called
> `foo.gpg` (note the non-standard extension), the `#foo.gpg` file is just
> a symlink, a lockfile instead of the normal autosave.
>
> This is probably because it would be prohibitively expensive to
> constantly call gpg every time a buffer changes to do the autosave. I
> think that is actually a fairly reasonable tradeoff.

if it's prohibitively expensive to encrypt-when-saving on a modern
machine, then we should be using a different encryption tool.

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


More information about the notmuch mailing list