[Top][All Lists]

[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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]