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, pgf(_at_)foxharp(_dot_)boston(_dot_)ma(_dot_)us (arlington, ma,
where it's 23.9 degrees)
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers