Hi David,
but when I look inside the message, the first alternative is
text/plain and the second is text/html - mhlist is lying to me.
mhlist isn't lying. You define the order of alternatives differently
than it does. You don't have to like it, but it's not lying.
I'd argue mhlist's current behaviour is correct and was explicitly
chosen rather than being an implementation artifact. That nmh doesn't
allow the user to specify an ordering preference over alternatives, e.g.
RTF trumps HTML, for mhshow or mhlist, is nmh's problem. One that
hopefully will improve soon. But it won't help with...
If I were to write a script (not using mhstore, but sed) to save the
text/plain part, I'd get the html variant instead. That's just
broken.
The sed script would be broken, not mhlist. No doubt we disagree on
that, but you and Ken haven't been able to convince me otherwise.
This seems to be a conflict between nmh as an MUA and as a toolkit for
parsing MIME emails. Perhaps the oft-mentioned canonical mail format
could make the MIME structure more straightforward to examine from
scripts, e.g. boundary separators that reflect the parts' position and
content allowing `sed /foo/,/bar/'-type extraction.
mhlist could grow a -raworder switch just for this issue, but that seems
a bit icky.
Cheers, Ralph.
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers