Re: [Nmh-workers] semantics of mhshow -type and -part

[Paul Fox]

david wrote:
 > Paul F. wrote:
 > 
 > > david wrote:
 > >  > Paul F. wrote:
 > >  >
 > >  > > 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 not sure about that.  My phone seems to handle it
 > >  > (multipart/alternative) nicely.
 > >
 > > and nmh does (or could) too, right now, if we were all willing to
 > > hand html mail to our browsers for display.  but most of would
 > > prefer to see text/plain over text/html,
 > 
 > mhn.defaults, by default, prefers text/html over text/plain.
 > You know that you can override that, right?

really?  how do i tell nmh to _prefer_ text/plain over text/html?  i'll
be genuinely shocked if there's a way.

i can block a type/subtype, or change the commands used to display that
type/subtype, but to my knowledge i can't tell mh to "prefer" one over
another in a way that wasn't expressed by the sender.  so i have a big
wrapper script littered with things like this:

    ptext()
    {
        MHSHOW=$Mail/mhn.block_html \
            mhshow -type text/plain "$@" | hilite | less
    }

    phtml_viewer()
    {
        MHSHOW=$Mail/mhn.html_live \
            mhshow -noconcat -type text/html "$@"
    }

    phtml_dump()
    {
        MHSHOW=$Mail/mhn.html_dump \
            mhshow -noconcat -type text/html "$@" | hilite | less
    }

and i also have an mh "part viewer" script that gives me one-keystroke
access to viewing any part of a message using the various viewers that
i prefer.  writing that has made my mime life tolerable, for the most
part.

 > 
 > > or perhaps even choose which based on sender.
 > 
 > That's messier with mhn.defaults and/or the profile, but still
 > doable.

yup.  currently i don't select based on the sender, but i do
select based on the current folder:
        ...
        case $whoami-$curfold in
        pgf-nedod)  ptext $arg ;;
        pgf-rides)  ptext $arg ;;
        *)          pdefault $arg ;;
        esac
        ...

the sender's preferences have little to do with how i read my mail.


 > 
 > > i'd like to see that made easier than it is
 > > now, because while its nice to know what the "sender" would prefer
 > > me to look at, that preference can be difficult for me to
 > > accomodate.
 > >
 > >  >
 > >  > On the other hand, I have been getting emails with text/html and
 > >  > text/plain in a multipart/related.  But those two text parts
 > >  > appear to be just different representations of the same content,
 > >  > so they really should be in a multipart/alternative.  I had been
 > >  > thinking that these are mistakes.  But now I wonder if that's the
 > >  > sender's way of punting the choice to the recipient.
 > >
 > > does it matter?  again, this suggests that we need better mechanisms
 > > for choosing among alternative mime parts in ways that are somewhat
 > > independent of the sender's supposed preference.
 > 
 > In this case, the sender isn't indicating a preference.  So mhshow
 > shows all the alternatives.  I find that annoying, but at least
 > it's easy to avoid.

i'm just wishing all these problems should be so easy.

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