🚀 go-pugleaf

Tim Freedom <tim_freedom@hotmail.com> wrote:
 > Kevin Rodgers writes:
 > >
 > > Tim Freedom wrote: 
 > > > I'm using VM-7.07 on emacs-21.2.3 and recently got a pdf attachment
 > > > that is bafflling me.  Here is my INBOX Summary,
 > > > 
 > > >   507  Joe Schmo  Jul 24  201245/13163128  "new spec"
 > > > 
 > > > The mime header notes the following,
 > > > 
 > > >   Content-Type: application/octet-stream;
 > > > 	  name="new_spec.pdf"
 > > >   Content-Transfer-Encoding: quoted-printable
 > > >   Content-Disposition: attachment;
 > > > 	  filename="new_spec.pdf"
 > > > 
 > > > the quirk is I click to save the attachment and wait and wait...
 > > > 
 > > > After about an hour worth of waiting (on a pretty decent SUN
 > > > machine with 2GB of Ram), I get the following message (note
 > > > the attachment is not saved either).
 > > > 
 > > >      Warning: memory in use exceeds lisp pointer size
 > > >      Killing some buffers may delay running out of memory.
 > > >      However, certainly by the time you receive the 95% warning,
 > > >      you should clean up, kill this Emacs, and start a new one.
 > > > 
 > > > What's going on ?  Others who were CC'ed on the email were able
 > > > to save-off the attachment, view it, etc (they're using other mail
 > > > clients).
 > > 
 > > VM is decoding the attachment within Emacs.  Do you have an external QP
 > > decoder installed?  (You can get one in the VM source distribution.)
 > > Have you set vm-mime-qp-decoder-program and vm-mime-qp-decoder-switches
 > > accordingly?
 > 
 > I've used VM's internal decoder for years now without so much as a hitch;
 > is it normal for a 13Meg file to take emacs down to "its knees" like this ?

I don't think I've ever tried to unpack anything this large.
Typically people put large files like this up on an FTP server and
mail a URL.

The internal Lisp-based decoder is going to be much slower than
anything C-based.  I don't know why it chews a lot of memory, but
some large buffers get created in the decoding process.

XEmacs users will have better internal support for base64 than
Emacs users due to VM's intentional avoidance of Emacs' base64
decoder.  Emacs' decoder is too unforgiving of some encoding
errors.