Hi Ken, > My -prefer is re-ordering parts 1 and 2, as I can show with mhlist. ... > I can select the text/html in this case with > > $ mhlist -nov -prefer text/plain -prefer multipart/related ... > > Typically, the text/plain and text/html are children of the same > > multipart/alternative, but here Apple thinks text/plain means images > > aren't required. Perhaps revenge for my never having purchased an > > Apple product. > > Ralph, as far as I can tell ... nmh is doing exactly what you asked. > You told it, "Hey, if you run across a multipart/alternative, please > give me the text/plain version in preference to all others". And > that's exactly what happened.
Yes, I know. I tried to get across I understood that by showing I can have multipart/related trump text/plain. > This would require a lot of special-case code; Or some general-purpose code. https://en.wikipedia.org/wiki/Tree_rewriting#Term_rewriting_systems It would also allow things like ditch-plain: (multipart/alternative (text/plain text/html)) → (text/html) if users want to ditch the text/plain parts, avoiding the need to keep adding more options to mhfixmsg(1) for the special cases. > But right now I think you're going to have to engage your brain. I often do. You're missing the important point. Currently a simple `-prefer text/plain' that seems obvious from the man pages has side effects that won't be wanted, and the man pages don't warn about them. I think Paul Fox and I shared an itch; to prefer text/plain over text/html. But the current, simple, solution doesn't achieve that. It states a preference for one MIME type over all previously listed ones, and every one not listed. The best approach with that logic seems to be $ mhlist -nov -prefer text/plain -prefer multipart msg part type/subtype size description 32753 multipart/alternative 418K 1 multipart/related 417K 1.1 text/html 721 1.2 image/jpeg 238K 1.3 image/png 69K 2 text/plain 134 $ but it still means the pecking order is multipart text/plain */* and not the better */* text/plain text/html that only demotes text/html in relation to text/plain and otherwise leaves well alone. IIRC, a `*' can't be given for type or subtype, and it certainly doesn't mean match only if nothing following matches. Perhaps a `-demote' is the short-term fix? -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers