* Re: Bug in multipart/alternative [not found] <87hfsp969d.fsf@mattdav.vip.best.com> @ 1999-04-18 11:05 ` Lars Magne Ingebrigtsen 1999-04-18 11:49 ` Bruce Stephens 1999-04-20 4:31 ` François Pinard 0 siblings, 2 replies; 9+ messages in thread From: Lars Magne Ingebrigtsen @ 1999-04-18 11:05 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Bug in multipart/alternative 1999-04-18 11:05 ` Bug in multipart/alternative Lars Magne Ingebrigtsen @ 1999-04-18 11:49 ` Bruce Stephens 1999-04-18 18:05 ` Lars Magne Ingebrigtsen 1999-04-18 18:38 ` Peter von der Ahé 1999-04-20 4:31 ` François Pinard 1 sibling, 2 replies; 9+ messages in thread From: Bruce Stephens @ 1999-04-18 11:49 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Bug in multipart/alternative 1999-04-18 11:49 ` Bruce Stephens @ 1999-04-18 18:05 ` Lars Magne Ingebrigtsen 1999-04-18 18:37 ` Bruce Stephens 1999-04-20 13:28 ` Robert Bihlmeyer 1999-04-18 18:38 ` Peter von der Ahé 1 sibling, 2 replies; 9+ messages in thread From: Lars Magne Ingebrigtsen @ 1999-04-18 18:05 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Bug in multipart/alternative 1999-04-18 18:05 ` Lars Magne Ingebrigtsen @ 1999-04-18 18:37 ` Bruce Stephens 1999-04-20 13:28 ` Robert Bihlmeyer 1 sibling, 0 replies; 9+ messages in thread From: Bruce Stephens @ 1999-04-18 18:37 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Bug in multipart/alternative 1999-04-18 18:05 ` Lars Magne Ingebrigtsen 1999-04-18 18:37 ` Bruce Stephens @ 1999-04-20 13:28 ` Robert Bihlmeyer 1999-06-12 2:22 ` Lars Magne Ingebrigtsen 1 sibling, 1 reply; 9+ messages in thread From: Robert Bihlmeyer @ 1999-04-20 13:28 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Bug in multipart/alternative 1999-04-20 13:28 ` Robert Bihlmeyer @ 1999-06-12 2:22 ` Lars Magne Ingebrigtsen 0 siblings, 0 replies; 9+ messages in thread From: Lars Magne Ingebrigtsen @ 1999-06-12 2:22 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Bug in multipart/alternative 1999-04-18 11:49 ` Bruce Stephens 1999-04-18 18:05 ` Lars Magne Ingebrigtsen @ 1999-04-18 18:38 ` Peter von der Ahé 1999-04-18 19:33 ` Hrvoje Niksic 1 sibling, 1 reply; 9+ messages in thread From: Peter von der Ahé @ 1999-04-18 18:38 UTC (permalink / raw) >>>>> "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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Bug in multipart/alternative 1999-04-18 18:38 ` Peter von der Ahé @ 1999-04-18 19:33 ` Hrvoje Niksic 0 siblings, 0 replies; 9+ messages in thread From: Hrvoje Niksic @ 1999-04-18 19:33 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Bug in multipart/alternative 1999-04-18 11:05 ` Bug in multipart/alternative Lars Magne Ingebrigtsen 1999-04-18 11:49 ` Bruce Stephens @ 1999-04-20 4:31 ` François Pinard 1 sibling, 0 replies; 9+ messages in thread From: François Pinard @ 1999-04-20 4:31 UTC (permalink / raw) Cc: ding 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~1999-06-12 2:22 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <87hfsp969d.fsf@mattdav.vip.best.com> 1999-04-18 11:05 ` Bug in multipart/alternative Lars Magne Ingebrigtsen 1999-04-18 11:49 ` Bruce Stephens 1999-04-18 18:05 ` Lars Magne Ingebrigtsen 1999-04-18 18:37 ` Bruce Stephens 1999-04-20 13:28 ` Robert Bihlmeyer 1999-06-12 2:22 ` Lars Magne Ingebrigtsen 1999-04-18 18:38 ` Peter von der Ahé 1999-04-18 19:33 ` Hrvoje Niksic 1999-04-20 4:31 ` François Pinard
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).