Re: Bug in multipart/alternative

Re: Bug in multipart/alternative

[Lars Magne Ingebrigtsen]

Here's an interesting bug report:

> I've run into a case where the logic that chooses which alternative in
> a multipart/alternative breaks down.  If the message is just:
> 
> multipart/alternative
> 	text/plain
> 	text/html
> 
> the text/plain gets chosen (correct, because I don't have w3).  But if
> the message is:
> 
> multipart/alternative
> 	text/plain
> 	multipart/related
> 		text/html
> 		image/gif
> 
> The text/html gets chosen.  I see raw html in the article buffer.

Well, Gnus prefers the multipart/related over text/plain, so it
selects that.  And then it turns out that Gnus can't display the base
part of the multipart/related.

What on earth should one do?  Should there be a test for multipart/*
to see whether (after iterating over the arbitrarily complex tree)
Gnus really can display it after all?  

-- 
(Domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Magne Ingebrigtsen

Re: Bug in multipart/alternative

[Bruce Stephens]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

> Well, Gnus prefers the multipart/related over text/plain, so it
> selects that.  And then it turns out that Gnus can't display the
> base part of the multipart/related.
> 
> What on earth should one do?  Should there be a test for multipart/*
> to see whether (after iterating over the arbitrarily complex tree)
> Gnus really can display it after all?

Why not?  Lisp is good at recursion, after all.

Re: Bug in multipart/alternative

[Lars Magne Ingebrigtsen]

Bruce Stephens <bruce@cenderis.demon.co.uk> writes:

> > What on earth should one do?  Should there be a test for multipart/*
> > to see whether (after iterating over the arbitrarily complex tree)
> > Gnus really can display it after all?
> 
> Why not?  Lisp is good at recursion, after all.

Yes, but I'm having difficulty envisioning the predicate function
here.  What are the rules we are after, really?

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

Re: Bug in multipart/alternative

[Bruce Stephens]

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

> Bruce Stephens <bruce@cenderis.demon.co.uk> writes:
> > 
> > Why not?  Lisp is good at recursion, after all.
> 
> Yes, but I'm having difficulty envisioning the predicate function
> here.  What are the rules we are after, really?

I see what you mean.  How about splitting it into two: first, use
recursion to enumerate all the displayable alternative bits; then,
apply whatever preference rules there are to determine the optimal one
to display?

I suppose that's potentially expensive, but trivial in this case, I
suspect.

Re: Bug in multipart/alternative

[Peter von der Ahé]

>>>>> "BS" == Bruce Stephens <bruce@cenderis.demon.co.uk> writes:

 BS> Why not?  Lisp is good at recursion, after all.

Some Lisp variants are, but not Emacs Lisp, here is a cut from the
Tips section of the elisp info pages:

Tips for Making Compiled Code Fast

   Here are ways of improving the execution speed of byte-compiled Lisp
programs.

...

   * Use iteration rather than recursion whenever possible.  Function
     calls are slow in Emacs Lisp even when a compiled function is
     calling another compiled function.

Kind Regards
Peter

Re: Bug in multipart/alternative

[Hrvoje Niksic]

pahe@daimi.au.dk (Peter von der Ahé) writes:

> >>>>> "BS" == Bruce Stephens <bruce@cenderis.demon.co.uk> writes:
> 
>  BS> Why not?  Lisp is good at recursion, after all.
> 
> Some Lisp variants are, but not Emacs Lisp,

This is irrelevant -- the manual is talking about efficiency, like
when you intend to traverse huge trees recursively into depths of
several hundreds, or when you (heaven forbid!) think tail recursion
elimination might happen (it won't).

Recursion for traversing MIME parts should be just fine.

Re: Bug in multipart/alternative

[François Pinard]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

> Well, Gnus prefers the multipart/related over text/plain, so it selects
> that.  And then it turns out that Gnus can't display the base part of
> the multipart/related.  What on earth should one do?  Should there be a
> test for multipart/* to see whether (after iterating over the arbitrarily
> complex tree) Gnus really can display it after all?

Yes.  My feeling is that Gnus should display the last alternative which it
knows how to display correctly.  If it has no way to display some necessary
part of an alternative, then that alternative cannot be displayed correctly,
and so, should be ignored (unless it is the only choice, of course).

-- 
François Pinard                            mailto:pinard@iro.umontreal.ca
Join the free Translation Project!    http://www.iro.umontreal.ca/~pinard

Re: Bug in multipart/alternative

[Robert Bihlmeyer]

Hi,

>>>>> On 18 Apr 1999 20:05:14 +0200
>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org> said:

 >> > What on earth should one do? Should there be a test for
 >> > multipart/* to see whether (after iterating over the arbitrarily
 >> > complex tree) Gnus really can display it after all?
[...]

 Lars> Yes, but I'm having difficulty envisioning the predicate
 Lars> function here. What are the rules we are after, really?

A part is displayable, if
a) it is a non-aggregate (text/*, image/*, ...), and the usual tests
   succeed (can this Emacs display html, gif, etc.)
b) it is a multipart/alternative, and one of its subpart is
   displayable
c) is is a multipart/*, and all its subparts are displayable

b+c do the recursion thingy.

	Robbe

-- 
Robert Bihlmeyer	reads: Deutsch, English, MIME, Latin-1, NO SPAM!
<robbe@orcus.priv.at>	<http://stud2.tuwien.ac.at/~e9426626/sig.html>

Re: Bug in multipart/alternative

[Lars Magne Ingebrigtsen]

Robert Bihlmeyer <e9426626@stud2.tuwien.ac.at> writes:

> A part is displayable, if
> a) it is a non-aggregate (text/*, image/*, ...), and the usual tests
>    succeed (can this Emacs display html, gif, etc.)
> b) it is a multipart/alternative, and one of its subpart is
>    displayable
> c) is is a multipart/*, and all its subparts are displayable
> 
> b+c do the recursion thingy.

Yup.  Anyone want to write the predicate for me?  I've been doing
financial programming for over a month, so I don't know from logic any
more.  :-)

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