># 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 [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
