[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] Ordering of Parts by mhlist.

From: Ken Hornstein
Subject: Re: [Nmh-workers] Ordering of Parts by mhlist.
Date: Fri, 19 Apr 2013 08:53:27 -0400

>     msg part  type/subtype              size description
>    19696       multipart/alternative     4785
>         1     text/html                 2787
>         2     text/plain                1680
>    $
>The email has subtype plain first, then html.  I know this from show(1)
>so it's then a bit odd to then see them flipped by mhlist.  Does mhlist
>deliberately rank html above text?  Is it alphabetical?

Huh, you know what, you're right.  I never noticed that before.

Ah-HA.  This is deliberate.  For multipart/alternative, it's intentionally
reversed.  See the following code in mhparse.c:

    /* reverse the order of the parts for multipart/alternative */
    if (ct->c_subtype == MULTI_ALTERNATE)
        reverse_parts (ct);

So, why is it that way?  You've got me.  It's been that way in nmh
as far back as the revision history goes.

"Stock" MH 6.8.5 did not have a reverse_parts() function, but I see code
in mhn that did the same thing (boy, I keep forgetting how much cleanup
Richard Coleman did).  Acccording to the RCS logs, that code was around
from the initial checkin of mhn.c by John Romine in 1992, which is as far
back as we have.  I lack the energy to dig back in history farther.

So, in summary: it's always been that way, if by "always" we mean "at
least 20 years".  If I had to guess, I would say that it was done that
way because alternative parts are supposed to be listed in order from
least preferred to most preferred, and the original authors of the MIME
code in MH wanted the most prefered one listed first (probably because
you could then set up things to automatically skip over content you
couldn't display).

Since it's been that way forever, I'd want us to think about it before
we changed it.  Also, the implications for MIME processing need to be
looked at carefully; that code is a mess.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]