>> It's obvious that was done because otherwise, you could never give a >> consistent -part switch (it wouldn't make any sense if mhlist showed >> a part number of 1, but in mhshow it was really 2). > >I don't follow, but that doesn't matter. It makes >sense to me the way it is now, so I don't want it to >change.
I guess my points are: - Looking back at the actual implementation, it is clear (to me at least) that the parts were reversed to make it simpler on the code that displayed multipart/alternatives; it was easy enough to bail out when it found the first one that was the "best" it could display. The fact that what ended up being mhlist does the same was just an artifact of the implementation (the reversing happens during MIME parsing). - It doesn't make sense to me, since it's the opposite of the order of the parts in the actual message (and this isn't, AFAICT, documented anywhere ... well, okay, I see that you added that in 2013). Everywhere else, the part numbering is based on actual order. I suspect most people won't really care ... so far the number of people who have noticed this is you, me, and Ralph. I know I said back then that we should leave it as-is, but if we're redoing the MIME parser and display code I think this wart should be fixed. - I cannot say what other MUAs do; the only other one that I know that exposes the order of multipart/alternative parts is exmh, and that displays them in message order (and this is kind of confusing when you're looking at the same message in two different MUAs). --Ken _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
