Re: [Nmh-workers] problem with mhshow after mhfixmsg

[Paul Fox]

ken wrote:
 > >i'm having a problem with mhshow showing some of the parts
 > >of a message, but only after the message has been run through
 > >mhfixmsg.
 > >
 > >before i start debugging mhshow (which i'm willing to do, though
 > >it will take me a while), i want to be sure that the output of
 > >mhfixmsg is valid MIME.
 > 
 > Okay, so I took a look at this and I can reproduce it.  It's not mhfixmsg's
 > fault.
 > 
 > The fault is because of the ... unusual (but valid) structure of this
 > message, and the logic inside of show_multi_internal().

thankyouthankyou.  david did some preliminary investigation, and then
punted to me (offline).  i was just about to delve in, and having been
in there before, i was sure my head would explode somewhere along the
way.  (such a mess when that happens.)

your explanation is great.  i'll think about what might fix it, but
if you really think you'll be rewriting, i'm willing to let it slide
if it gets tricky feeling.

paul

 > 
 > At the top level, this message has a multipart/alternative, and enters
 > show_multi_internal().  This sets alternating, but not alternate, which
 > is correct:
 > 
 > /*
 >  * alternate   -> we are a part inside an multipart/alternative
 >  * alternating -> we are a multipart/alternative
 >  */
 > 
 > The two sub-parts of the top-level multipart/alternative are a text/plain
 > and a multipart/related.
 > 
 > The multipart/related is decended into.  It contains a multipart/alternative
 > and multiple image/jpegs.  The sub-parts of THAT multipart/alternative are
 > a text/plain and text/html.  Both of the attempts to view the those
 > parts fail (because part_ok() returns false for both of them).
 > 
 > But THAT causes show_multi_internal() to return NOTOK.  Why?
 > Well, alternate is passed down as "true" from the top-level
 > multipart/alternative type.  The default return code for
 > show_multi_internal() is set to NOTOK if alternate is set.
 > And when processing the multipart/related, alternate is true (because
 > we're under the top-level multipart/alternative) but alternating
 > is false (because multipart/related is not an alternate part itself).
 > That short-circuits the multipart/related processing and it bails
 > out at that point; that bubbles up to the top-level alternative part
 > and you get the resulting error.
 > 
 > Are you confused?  I sure was.
 > 
 > As for a fix ... crud, I don't know.  I am reluctant to mess with that
 > alternative part processing, as it's kind of a mess (I was planning on
 > rototilling it for the next release).
 > 
 > --Ken
 > 
 > _______________________________________________
 > Nmh-workers mailing list
 > address@hidden
 > https://lists.nongnu.org/mailman/listinfo/nmh-workers

=----------------------
 paul fox, address@hidden (arlington, ma, where it's 40.6 degrees)