>> But right now I think you're going to have to engage your brain.
>I often do.  You're missing the important point.  Currently a simple
>`-prefer text/plain' that seems obvious from the man pages has side
>effects that won't be wanted, and the man pages don't warn about them.

Ok, that's fair and I see where you're going; translating that into
actual running code might be "fun", but I'll let you work on that :-)

But ... I think you are missing my larger point, which I don't think
was that obvious so I'll put the blame on me.

You are attempting to apply logical rules to something that does not,
as far as I can tell, HAVE any logical rules.  Yes, the MIME standards
do talk about how multipart/alternative works, but the actual nitty
gritty of actually dealing with a message that has the structure you've
encountered is ... well, it's a bit unspecified, isn't it?  It's not
clear to me what the MUA author was thinking when they wrote the code to
generate that message; maybe they were thinking, "Well, if someone is
still using an 1980's-era mailx, we'll put the text/plain first so they
can at least read SOMETHING, but for everyone else we'll put the REAL
information in the other component of the multipart/alternative".

Yes, you could probably write some code to rewrite this message
structure to get what you want.  That might work for THIS MUA, THIS time
... there's no guarantee that it will work for whatever is generated by
the next version of <insert MUA here>.  I know you and Paul Fox (and
plenty of others!) share this desire to prefer the text/plain component
of a message, and I can understand that desire and even partially share
it ... but I think ultimately it is swimming against the tide and will
just cause you more problems in the long run.  I am seeing more and more
messages where the text/plain component of a message is actually from
ANOTHER, older message; I'm not sure how you get something so broken,
but that seems to be the reality of the world we live in.



Reply via email to