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

[Antoine Beaupré]

On 2019-11-14 03:16:51, Daniel Kahn Gillmor wrote:
> 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.

Possibly.

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

I would just hate to think of notmuch as a (yet another) Emacs MUA that
reinvents everything for itself, with nice little "edges" compared to
the other clients. But I guess that's the easier way to move forward and
I would certainly prefer that to not having a solution for this. :)

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

The individual calls are not what's prohibitively expensive. The problem
is latency. Even if it just takes 100ms[1] to save the file to the disk,
that's a huge delay in terms of human interface, because the entire
Emacs UI will *freeze* for that amount of time whenever it thinks it
should do an autosave.

So yes, that's prohibitively expensive, and I'm not sure it's realistic
to blame gpg for this here. We are, after all, shelling out to a
different process and most runtimes have at least *some* overhead on
started (e.g. cPython 2 is ~13ms here and cPython 3 is around 25ms, both
noticeable latencies).

In other words, maybe the right solution for autosave is to skip it in
some cases.

A.

[1] anarcat at curie:~(master)$ multitime -n 10 -r 'rm -f motd.gpg' -v gpg -e -r anarcat at debian.org motd
===> multitime results
1: -r "rm -f motd.gpg" gpg -e -r anarcat at debian.org motd
            Mean        Std.Dev.    Min         Median      Max
real        0.096       0.007       0.088       0.099       0.104       
user        0.062       0.011       0.041       0.061       0.080       
sys         0.023       0.008       0.012       0.023       0.037       


-- 
There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult.
                        - C.A.R. Hoare