Inline MIME display -- when and when not?

Inline MIME display -- when and when not?

[Lloyd Zusman]

I just installed `pgnus-0.56' along with the recommended `w3' stuff.
I'm running XEmacs 20.4.

In an earlier `pgnus' release (I'm not sure which ... perhaps in
the 0.40-0.50 range), I noticed the following behavior:

I receive a message with multipart/mixed stuff in it, and each part
contains a MIME-encoded jpeg image (image/jpeg).  When I use the `b'
command with a numerical prefix to view the N-th MIME part, the image
gets rendered right inside my XEmacs article buffer.

Now, when I'm accessing the very same message with the very same jpeg
images using 0.56 with the `w3' stuff, `xv' gets fired off to view the
images when I use the `b' command.

The only thing which I changed at my site is the version of `pgnus'
and the addition of the recommended `w3' stuff.  Everything else is
the same.

I'd like to be able to specify that these jpeg images get viewed
inline (within my XEmacs article buffer) and not via `xv', but I don't
know how to control this behavior.  Is this done via `pgnus' or via
`w3'?  I've looked through the latest 0.56 `info' documentation, and I
can't find anything about this.  Perhaps this is something which was
discussed in recent weeks here in the mailing list, but if so, I
missed it.

Could anyone steer me to the proper documentation about this, or
if none exists, to point me to the proper functions and variables
which control this behavior?

Thanks in advance.

-- 
 Lloyd Zusman
 ljz@asfast.com

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

[Lars Magne Ingebrigtsen]

Lloyd Zusman <ljz@asfast.com> writes:

> Now, when I'm accessing the very same message with the very same jpeg
> images using 0.56 with the `w3' stuff, `xv' gets fired off to view the
> images when I use the `b' command.

The inline media tests have changed.  Gnus won't display images that
are bigger than the article buffer inline.  Perhaps there should be an 
option to switch this feature off?  Or perhaps a command to display
things inline, no matter if we can or not?  Hm.  But if we can't, how
can we?  :-)

It seems we have "hard" requirements (eg., if we are in Emacs 20.3, we 
can't display images inline) and "soft" requirements (eg., the image
is too big to display prettily)...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

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

[Lloyd Zusman]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> [ ... ]
> 
> The inline media tests have changed.  Gnus won't display images that
> are bigger than the article buffer inline.  Perhaps there should be an 
> option to switch this feature off?  Or perhaps a command to display
> things inline, no matter if we can or not?  Hm.  But if we can't, how
> can we?  :-)

Well, the pictures in question used to fit into the article buffer
just fine in the earlier version of `pgnus' I mentioned.  Perhaps
there's currently an error in the logic which determines whether or
not the images will fit in the buffer ... ???

> [ ... ]

-- 
 Lloyd Zusman
 ljz@asfast.com

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

[Hrvoje Niksic]

Lloyd Zusman <ljz@asfast.com> writes:

> Well, the pictures in question used to fit into the article buffer
> just fine in the earlier version of `pgnus' I mentioned.  Perhaps
> there's currently an error in the logic which determines whether or
> not the images will fit in the buffer ... ???

Hmm.  It works correctly for me.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Q: What's an IBM man-year?
A: 730 people trying to get a project done before noon.

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

[Lloyd Zusman]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> [ ... ]
> 
> The inline media tests have changed.  Gnus won't display images that
> are bigger than the article buffer inline.  Perhaps there should be an 
> option to switch this feature off?  Or perhaps a command to display
> things inline, no matter if we can or not?  Hm.  But if we can't, how
> can we?  :-)

OK.  I figured out what's going on for me.  The width of my images
were all less than the width of the article buffer, but the heights of
the images were longer than the buffer, thereby causing the
`mm-image-fit-p' routine in `mm-decode.el' to consider the image to be
too big for the buffer.

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.  Wouldn't it be acceptable to
allow a longer-than-buffer image to still be drawn inline, as long as
it's narrow enough?

My opinion is that there should at least be an option to control this
behavior with regard to the vertical dimension of the image.

> [ ... ]

-- 
 Lloyd Zusman
 ljz@asfast.com

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

[Hrvoje Niksic]

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.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
The Lord protects children and fools...  But don't push it.

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

[Lloyd Zusman]

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?

-- 
 Lloyd Zusman
 ljz@asfast.com

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

[Lloyd Zusman]

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

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

[Hrvoje Niksic]

Lloyd Zusman <ljz@asfast.com> writes:

> 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.

Related to crashes: some of the image code has been revamped for 21.x;
you may wish to compile a 21.0 beta and see if the crashes disappear.

> 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.

The file descriptor leakage you describe sounds familiar.  I think
this has also been fixed in 21.0.

> But prior to these errors occurring, taller-than-buffer images
> display perfectly fine, both inline within my article buffer,

As explained elsewhere, this cannot be true, at least for the values
of "perfectly fine" that I'm using.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Q: What's an IBM man-year?
A: 730 people trying to get a project done before noon.

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

[Lloyd Zusman]

Hrvoje Niksic <hniksic@srce.hr> writes:

> Lloyd Zusman <ljz@asfast.com> writes:
> 
> > [ ... ]
> 
> Related to crashes: some of the image code has been revamped for 21.x;
> you may wish to compile a 21.0 beta and see if the crashes disappear.

I'll give it a try.

> > [ ... ]
>
> The file descriptor leakage you describe sounds familiar.  I think
> this has also been fixed in 21.0.

Given these errors in XEmaces versions < 21.0 for images displayed
inline *and* via an external viewer, shouldn't perhaps the older
method for viewing images be used?  It doesn't seem right to be making
use of an image viewing method that only works in a beta version of
XEmacs.  Once XEmacs becomes "final", perhaps we could then start
using the newer method.

I never had problems with images when the older viewing method was
used, whether they showed up inline or were displayed via an external
viewer.

> > But prior to these errors occurring, taller-than-buffer images
> > display perfectly fine, both inline within my article buffer,
> 
> As explained elsewhere, this cannot be true, at least for the values
> of "perfectly fine" that I'm using.

Well, it is indeed true that we disagree on the meaning of "perfectly
fine", since as I mentioned earlier, the current behavior is OK with
me (as long as I can avoid the crashes and file descriptor leakage).
Given that some of us (one of us?) find the current behavior to be
acceptable, this does seem to indicate that an option controlling
taller-than-buffer images might be in order.  The default could be to
not display them inline.

Of course, I could always hack my own `mm-image-fit-p' via `defadvice'
or some other method, if no option is provided ... :)

-- 
 Lloyd Zusman
 ljz@asfast.com

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

[Hrvoje Niksic]

Lloyd Zusman <ljz@asfast.com> writes:

> > > [ ... ]
> >
> > The file descriptor leakage you describe sounds familiar.  I think
> > this has also been fixed in 21.0.
> 
> Given these errors in XEmaces versions < 21.0 for images displayed
> inline *and* via an external viewer, shouldn't perhaps the older
> method for viewing images be used?  It doesn't seem right to be
> making use of an image viewing method that only works in a beta
> version of XEmacs.

I don't understand what "older method" you are referring to.  Leaking
file descriptors when xv is started is an XEmacs bug, and there is
nothing Gnus can do about it.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
"Silence!" cries Freydag. "I did not call thee in for a consultation!"
"They are my innards! I will not have them misread by a poseur!"

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

[Lloyd Zusman]

Hrvoje Niksic <hniksic@srce.hr> writes:

> Lloyd Zusman <ljz@asfast.com> writes:
> 
> > > > [ ... ]
> > >
> > > The file descriptor leakage you describe sounds familiar.  I think
> > > this has also been fixed in 21.0.
> > 
> > Given these errors in XEmaces versions < 21.0 for images displayed
> > inline *and* via an external viewer, shouldn't perhaps the older
> > method for viewing images be used?  It doesn't seem right to be
> > making use of an image viewing method that only works in a beta
> > version of XEmacs.
> 
> I don't understand what "older method" you are referring to.  Leaking
> file descriptors when xv is started is an XEmacs bug, and there is
> nothing Gnus can do about it.

Lars talked about "inline media tests" having recently changed, and I
was thinking about this.  But I guess this must mean that there is now
a difference in `mm-image-fit-p' or something similar, instead of some
sort of basic change in the logic used for decoding/displaying MIME
attachments.  I erroneously assumed from Lars' words that there *had*
been such a basic change, since I could swear that I had no trouble
firing off as many external viewers as I wanted in earlier `pgnus'
versions, not to mention viewing the inline images without any
crashes.  But perhaps I'm mistaken ... ???

-- 
 Lloyd Zusman
 ljz@asfast.com

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

[Lars Magne Ingebrigtsen]

Lloyd Zusman <ljz@asfast.com> writes:

> Lars talked about "inline media tests" having recently changed, and I
> was thinking about this.

The variable `mm-inline-media-tests' has changed...

> But I guess this must mean that there is now
> a difference in `mm-image-fit-p' or something similar,

... to include calls to `mm-image-fit-p'.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

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

[Hrvoje Niksic]

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

How could it have possibly worked fine?  You mean that you had an
image taller than the window, and you were able to see its bottom by
using the scrollbar?  What version of XEmacs are you using?  I want
it!  :-)

What you describe has never worked right.  XEmacs supports line
clipping only on the bottom of the screen, not at the top.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
"Listen, kid, we're all in it together!" -- Harry Tuttle in _Brazil_

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

[Lloyd Zusman]

Hrvoje Niksic <hniksic@srce.hr> writes:

> [ ... ]
> 
> How could it have possibly worked fine?  You mean that you had an
> image taller than the window, and you were able to see its bottom by
> using the scrollbar?  What version of XEmacs are you using?  I want
> it!  :-)

To clarify:

The "scrolling" I'm referring to is not scrollbar-based scrolling.  I
don't even use scrollbars in my XEmacs windows.  I'm referring to
scrolling that is done via `gnus-summary-scroll-up' and
`gnus-summary-next-page'.

> What you describe has never worked right.  XEmacs supports line
> clipping only on the bottom of the screen, not at the top.

Yes.  I observe this.  I can scroll to see more and more of the image
appearing at the bottom of the screen, but I cannot scroll in the
opposite manner.  Nonetheless, this is acceptable behavior for me.

-- 
 Lloyd Zusman
 ljz@asfast.com

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

[Hrvoje Niksic]

Lloyd Zusman <ljz@asfast.com> writes:

> Hrvoje Niksic <hniksic@srce.hr> writes:
> 
> > [ ... ]
> > 
> > How could it have possibly worked fine?  You mean that you had an
> > image taller than the window, and you were able to see its bottom by
> > using the scrollbar?  What version of XEmacs are you using?  I want
> > it!  :-)
> 
> To clarify:
> 
> The "scrolling" I'm referring to is not scrollbar-based scrolling.  I
> don't even use scrollbars in my XEmacs windows.  I'm referring to
> scrolling that is done via `gnus-summary-scroll-up' and
> `gnus-summary-next-page'.

I am unable to make it work the way you describe it.  For me, it is
simply impossible to see the bottom of an image taller than the
window, in any version of XEmacs I have seen in my life.

> > What you describe has never worked right.  XEmacs supports line
> > clipping only on the bottom of the screen, not at the top.
> 
> Yes.  I observe this.  I can scroll to see more and more of the
> image appearing at the bottom of the screen, but I cannot scroll in
> the opposite manner.  Nonetheless, this is acceptable behavior for
> me.

Not seeing the image bottom is unacceptable to me.  Which doesn't mean 
I like the current approach, either.

For one, I can resize the window and/or the whole XEmacs.  Second,
current code makes display of article with images slow like hell.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
The Lord protects children and fools...  But don't push it.