Re: [Nmh-workers] (no subject)

[Ken Hornstein]

>> 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