🚀 go-pugleaf

Ciamac Moallemi on May 27 wrote:
-> I have found a potential bug in VM 5.32: when I incorporate new mail,
-> I am asked if I really wish to kill my vm-crash-box.  This is not a
-> big deal, but it gets quite annoying after a while.  Note that I have
-> vm-visit-when-saving set to t and vm-crash-box is in my
-> auto-mode-alist (associated with vm-mode, of course).
Kyle Jones on May 27 wrote:
-> Ciamac Moallemi writes:
> > I have found a potential bug in VM 5.32: when I incorporate new mail,
[...]
-> 
-> Emacs won't ask about the killng a buffer unless it has been
-> modified.  VM should not be doing anything that would modify the
-> crash box buffer.  So the question is: how is the crash box
-> buffer being modified?

After invoking vm-mode, all of the messages in the crash box are new,
and the first such message is being marked as read, which sets the
buffer modification flag to t.

Kyle Jones on May 27 wrote:
-> Ciamac Moallemi writes:
> > Isn't VM modifying the crash box buffer when it incorporates new mail?
> > I was under the impression that new mail is first deposited into the
> > crash box buffer, and then moved to the inbox.
-> 
-> The mail is moved into the crash box before it is visited by
-> VM/Emacs.  VM visits the crash box, appends its contents to the
-> inbox buffer and the on-disk version of the inbox, removes the
-> crash box and kills the crash box buffer.  None of these actions
-> should cause the buffer modification flag to be set in the crash
-> box buffer.

Except when the crash box is in the auto-mode-alist, vm-mode is
invoked and ... then when trying to kill the crash box (which is
marked modified), etc.

Two ways to solve this:

    Don't name the vm-crash-box so that it is in auto-mode-alist
or
    (setq vm-preview-lines "some number")

to avoid modification.  I have done both.

-Jerry