[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] semantics of mhshow -type and -part
From: |
David Levine |
Subject: |
Re: [Nmh-workers] semantics of mhshow -type and -part |
Date: |
Sat, 31 Jan 2015 16:07:33 -0500 |
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.
On the other hand, I'd be fine leaving the behavior as it is now.
It'd be nice to document it, of course.
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.
David