# Meh. Everywhere else nmh presents MIME parts in the order in
# which they occur in the message;
By "everywhere else", I mean the MIME parsing & display routines (really,
I meant "all other content"), but that wasn't clear. My apologies.
The parts are stored in reverse order in the message to make
them easier to view with non-MIME-conformant viewers. That is
irrelevant to a user of mhlist/mhstore. Why expose it?
I guess it's all about what you mean by "reverse" order. I mean, I
would say it's "least preferred first", but that's a semantic issue.
Or perhaps "actual order".
So, why expose it? Well, everywhere else we display the exact MIME
structure as it exists in the message. I found the exception for
multipart/alternative confusing, and it's non-obvious behavior if you
know about MIME. If you don't know about MIME ... well, you're probably
not looking at the output of mhlist very much, you're just letting mhshow
pick the best content for you to display.
same order. This is just another way of looking at why I think
it would be wrong to change mhlist. We'd have inconsistent
behavior.
I wasn't actually proposing to change just mhlist; what would happen
would be to simply delete the reverse_parts() function. I would have done
it back when I first discovered this, but that would have had implications
for the giantic mess that is mhshowsbr.c.
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers