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, pgf(_at_)foxharp(_dot_)boston(_dot_)ma(_dot_)us (arlington, ma,
where it's 14.0 degrees)
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers