[Nmh-workers] overriding multipart/alternative ordering

[Paul Fox]

ralph wrote:
 > Hi Paul,
...
 > > as an aside, i actually think "the sender's ranking" is a highly
 > > overrated, and possibly even obsolete concept these days, RFCs
 > > notwithstanding.
 > ...
 > > i'm all for nmh doing the RFC-correct thing by default, but i also
 > > think we should be making it dead easy for the the recipient to make
 > > their own type/subtype rankings to override the sender's purported
 > > choice.
 > 
 > Agreed.  nmh needs some way for me to say text/plain trumps text/html,
 > overriding the sender's ordering.

since i've been thinking about parts and types lately, i've just
implemented this, in the form of a new "-prefer content/type" switch,
to mhshow, mhlist, and mhstore.  here's an initial cut at the man page
text:

    In the absence of -prefer, MH will select the "favored" displayable
    subpart from multipart/alternative content.  The -prefer
    switch can be used (one or more times, in order of descending
    preference) to let MH know which content types from a
    multipart/alternative MIME part are preferred by the user, in order to
    override the default selection for display.  For example, mail is
    often sent containing both plaintext and HTML-formatted versions of
    the same content, and the HTML version is usually indicated to be the
    "best" format for viewing.  Using "-prefer text/plain" will cause the
    plaintext version to be displayed if possible, but still allow display
    of the HTML part if there is no plaintext subpart available. 
    (Implementation note:  RFC 2046 requires that the subparts of a
    multipart/alternative be ordered according to "faithfulness to the
    original content", and MH by default selects the subpart ranked most
    faithful by that ordering.  The -prefer switch reorders the
    alternative parts (only internally, never changing the message
    file) to move the user's preferred part(s) to the "most faithful"
    position.  Thus, when viewed by mhlist, the ordering of
    multipart/alternative parts will appear to change when invoked
    with or without various -prefer switches.)

i think this fills a long-empty hole in the MH interface.  the only
wart, i think, is that it depends on reordering the parts in a
user-visible way, which perhaps violates the principle of least
astonishment.  but it's a very clean code change, which i don't think
would be true if trying to do something similar later on in
mhshowsbr.c.

comments?

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