🚀 go-pugleaf

VM: 5.32 (beta)
Emacs: 18.57

Darrin Jewell (me) wrote:
> If the command vm-get-new-mail is called outside of a vm buffer, 
> it will report "No new mail." even if there is mail waiting.

Kyle Jones replied:
>I just tried this M-x vm-get-new-mail from the *scratch* buffer
>and the new mail was retrieved from the spool.

Looking at vm-get-new-mail and investigating this bug opened 
quite a can of worms.... There seems to be a number of problems in 
this routine.  As a quick example of how flaky this problem is, note
the following:  First, make sure that vm has been called, an
INBOX buffer in vm-mode exists, and there is new mail waiting.
Now, if you go to the "*scratch*" buffer and type M-x vm-get-new-mail,
it might work fine.  It won't work, however, unless the "*scratch*" buffer
is empty.  If there is anything in the scratch buffer, it simply claims 
"No new mail.", which isn't true.

I started hunting through the code with the debugger, and a number
of problems quickly become obvious.  I was surprised to see this
in a routine that could potentially cause disaster with lost mail.
Here's a few notes on what I have noticed so far.  I will investigate 
and perhaps fix some of this later, but I really don't have the time to 
be playing with this now. (whimper... but it's so much more fun 
than studying for finals... sigh)

First:
     The call to the macro vm-select-folder-buffer in the first
line of vm-get-new-mail fails because the variable vm-mail-buffer
is local to the vm-mode buffer.  When vm-get-new-mail is called
from outside the vm-mode buffer, its value is nil.  Therefore
it doesn't know what buffer to select.  

Secondly:
    The code in vm-get-new-mail assumes that vm-spool-file is a 
compatible folder with the current folder.  This isn't too bad because
both vm-check-for-spooled-mail and vm-get-spooled-mail call 
vm-compatible-folder-p.  They will both fail and return nil
if vm-compatible-folder-p returns nil.  However, since 
vm-get-spooled-mail returns nil, vm-get-new-mail then claims
that there is "No new mail."  It would probably be a better
idea if functions like vm-get-spooled-mail could handle
an error variable which it would set with a message to pass
back about  why it failed.

Thirdly:
    vm-compatible-folder-p also assumes it is already in the vm-mode 
buffer.  One of the first things it does is to check whether the current
buffer is empty [..i.e.(zerop (buffer-size))].  If so, it would assume 
that an empty buffer is always compatible and would automatically 
return true.  This is why in the above example, it worked if the
"*scratch*" buffer was empty, and didn't if it was not.  Also,
vm-compatible-folder-p uses the vm-folder-type variable which is
local to the vm-mode buffer and nil elsewhere.  It then compares
that nil to the "From_" folder type returned by vm-get-folder-type
and incorrectly determines that the folder is not compatible.

Fourthly:
    Most of the entire previous problem could probably be avoided if
the original vm-select-folder-buffer call had succeeded, but
there was no check for this.

Fifthly:  
     Not very important, but I thought I'd point it out.
The following construct found in vm-get-new-mail seems to me to be
redundant.  
    (or (get-file-buffer vm-primary-inbox)
        (find-file-noselect vm-primary-inbox)))
The function find-file-noselect will automatically attempt to 
get-file-buffer before it searches on the disk for the file, 
therefore the extra call to get-file-buffer is not necessary.

Sixthly:
    There is still a bug in the mail retrieval process somewhere
which causes it to signal some sort of wrong type argument error 
sometimes.  I haven't tracked it down or investigated it much yet.

Finally:
    It would be really useful if vm's internal functions were well
documented.  I'd be floating in heaven if I could C-h f on an 
internal function name and get it's arguments, what it returns,
what it does, and what sort of things it requires (for example,
does it assume it is in a folder buffer?)  This isn't really a 
serious request as I realize that it's way beyond
reality to go back and document the functions, but it would have
been very helpful in this case.  (I also will admit that I don't
usually document anywhere near that well, but after mucking around
with this it may just convince me to do so next time....)

Anyway... I hope some of this is useful.  Mucking around in elisp
code is much more fun than studying for my final on Monday,
(I seriously doubt the final will have any elisp code in it) which
is really what I should be doing.  I probably won't be able to play
with this much more right away, but if I come up with anything else
I'll let you know.  vm-get-new-mail could probably be cleaned up, but
then you run the risk of changes introducing new bugs.

   HAVE A DAY
     -darrin  (jewell@fenchurch.mit.edu)

Darrin Jewell ----------jewell@athena.mit.edu-----------------KA2ZLZ------
4 Ames Street |  Massachusetts Institute of Technology  | Darrin B. Jewell
Cambridge, MA |       Senior House -- Runkle 501        | 8 Thomaston Lane
USA     02142 |                                         | Orchard Park, NY
(617)225-6641 <- room, probably busy (modem)            | USA   14127-2526
(617)253-3191 <- house desk, leave message              | (716) 662-9440