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

[Paul Fox]

david wrote:
 > Ralph wrote:
 > 
 > > kre wrote:
 > > > Paul wrote:
 > > > >  msg part  type/subtype              size description
 > > > >   27       multipart/mixed           1534
 > > > >      1     multipart/alternative      845
 > > > >      1.1   text/enriched               33
 > > > >      1.2   text/html                  295
 > > > >      1.3   text/plain                  30
 > > > >      2     application/x-zip-compre    57 Dummy Attachment
 > > > >
 > > > > what should "mhshow -type text/enriched -type text/plain" do?
 > > > > mh currently just shows one of them.  again, i feel it should
 > > > > show both, but again, your (and ralph's) reasoning presumably
 > > > > says no.
 > >
 > > `mhshow -type text/plain -type image/png' should show no parts
 > > except those two.  And if there's a multipart/alternative and it
 > > contains both of those then the normal multipart/alternative rule
 > > applies; the sender ranked them by order and I get just one or else
 > > I'd see duplicate content.
 > 
 > I don't feel strongly about this case.  I can see your reasoning,
 > but I can also see kre's:
 > 
 > > > Treat multiple -type or -part switches almost as if they were
 > > > separate invocations of mhshow - if I ask for two types, I generally
 > > > want to get shown two parts (the difference from two separate mhshows
 > > > would be if both -types or a -type and -part (or even two -parts but
 > > > that is unlikely) happen to select the same element of the message.
 > 
 > That way, when a user specifies a -type with a type/subtype
 > argument, they get exactly what they ask for.  Just like with
 > -part.  With both of those, the multipart/alternative rule is
 > ignored.

it seems to me that if you're in the mode of specifying parts by
number, or by fully-qualified type, then you're long past caring about
"the sender's ranking", and as kre says, you probably want to see just
what you asked for.  (that's sort of how i got to my initial view
that an underspecified type (e.g., "-type text") should show all
matching parts -- but clearly that would mostly just cause redundancy
in the output.  ralph's suggestion of an override option for wanting
all matches makes more sense.)

as an aside, i actually think "the sender's ranking" is a highly
overrated, and possibly even obsolete concept these days, RFCs
notwithstanding.  the number of users that even know their mail is
being sent in multiple formats, let alone that make preferential
choices about their ranking, has to be minute.  (the latter group may
all be on this list. ;-)  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.

 > 
 > On the other hand, I'd be fine leaving the behavior as it is now.
 > It'd be nice to document it, of course.

that will certainly be done.  in fact, once it sounds like there's
consensus, and/or a few more folks have chimed in, i'll probably write
the man page section first.

 > I quickly tried a few cases and duplicate (different switches
 > selecting the same part) suppression does seem to work properly.
 > I thought that it did.

the tree walk only visits each message part once, so it never really
has a chance to show anything twice.

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