Re: [nmh-workers] multipart/related and -prefer.

[Ralph Corderoy]

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