Re: Inline MIME display -- when and when not?

[Lloyd Zusman <ljz@asfast.com>]

Lloyd Zusman <ljz@asfast.com> writes:

> Hrvoje Niksic <hniksic@srce.hr> writes:
> 
> > Lloyd Zusman <ljz@asfast.com> writes:
> > 
> > > I'm wondering, however, why the height of the image is being
> > > considered at all, given that the article buffer is always easily
> > > scrollable in the vertical direction.
> > 
> > Because it's not.  Try it with an image larger than the window.
> 
> I did try it, and it worked for fine for a few images but then it
> crashed XEmacs on the third or fourth image I was viewing.  All
> images, including those which worked, were taller than the buffer
> height returned by `(window-pixel-height)'.  Is this the problem
> you're referring to?

More info: in the set of images I'm referring to, Gnus fails whether
or not the images are displayed inline.  It's just that the
manifestation of the error differs depending on how the image is
displayed.

In the case where I'm displaying the images inline (by the way, I do
this by temporarily hacking `mm-image-fit-p' to always allow
taller-than-buffer images), the first few taller-than-buffer images
display fine, but then, I either get an "out of memory" error in
XEmacs, or XEmacs crashes altogether.

In the default case where the taller-than-buffer images are being
displayed via `xv', I can also view a few images just fine, but then,
XEmacs seems to hang forever waiting for the next `xv' process to
start.  I have to Control-G out of this.  Then, no more `xv' processes
can be started.

In both cases, it appears that the memory that is being used to do the
base64 decoding is not being freed, but I'm not sure about this.

But prior to these errors occurring, taller-than-buffer images display
perfectly fine, both inline within my article buffer, and also via
`xv'.  My guess is that once the "out of memory" bug is fixed, all
taller-than-buffer images will work fine when displayed inline and
via an external viewer.

-- 
 Lloyd Zusman
 ljz@asfast.com