Ken wrote:
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).
I still don't buy that. mhlist needs to be consistent with
the other programs.
And the argument that simpler implementation drove the
original behavior so we should fix it now just doesn't seem
compelling. Especially for MH/nmh.
- 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.
Can you explain that? I thought the whole point was that
the part numbers from mhlist can be used with other programs.
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 wouldn't call it a wart so I don't think it should be
"fixed". If you want to provide an option to list things in
the other order, that would be fine and harmless. But why
risk breaking scripts or anything else that might depend on
things the way they are now?
Is there anything *wrong* with the current behavior? I like
this:
1851 multipart/alternative 11K
1 text/html 8017
2 text/plain 3127
I see that part 1 is html so I stop and use that. I don't
have to keep looking, or to skip over the sometimes useless
text/plain.
The only purpose for worst-first was to support
non-MIME-conformant viewers. There's no need to expose that
in MIME tools now.
David
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers