🚀 go-pugleaf

I, like many other people, read mail both at work and at home.  I always
leave and emacs running in both places.  

Any time I forget to type "q" at my home vm before I go in to work, I lose
horribly.

This happens to me all the time.  Usually I'm able to pound out a kill -9
before the damage is done, but this time I lost mail.  This is a CRITICAL
BUG.

I had a VM visiting my inbox, with everything saved.

I went to another emacs, and made changes (ie, read mail.)  I quit that emacs.

I went back to the first emacs.  I noticed that I had forgotten to quit
before I went in to work.  There was NO "*" in the modelines, so I just typed
"q" thinking that this would be the same as just killing the buffers.

But what to my wondering eyes does appear but "Stuffing attributes..."

So I start leaning on the ^G key.  But no.  VM has thoughtfully bound
inhibit-quit to t.  No failsafe.  We are fucked.

Why wasn't I prompted with "INBOX has changed since visited or saved" as I
would have been with any other file?  I don't know.  I can only assume that
VM has overridden this crucial check somehow.

Kyle, you CAN'T just go around binding inhibit-quit with the reckless abandon
that you have been.  VM took nearly half a minute to "stuff attributes", which
I assume means it modified the buffer, and then wrote my file before
responding to my ^G.  Which means that you have both modified the buffer and
written the file as an (incredibly long) atomic operation.  Clearly this is a
bad idea.  Clearly this much locking is not necessary.

inhibit-quit should be used only to avoid leaving a data structure in an
inconsistent state, such as when reordering a list.  It should be used only in
code that is *provably correct*, which means that if you're running more than
fice or six lines of code inside of it, you're making a really big mistake.

An even better idea than using inhibit-quit when modifying a structure is to
make a copy of that structure, make your changes on the copy, and then install
the changes, which is probably already an atomic operation.  

If you're writing code that cannot be allowed to be aborted, you're almost
always writing the code in a bad way.  You'll be hard pressed to convince me
that any program needs to be non-interruptable for more than a few
milliseconds.  

	-- Jamie