Re: [Nmh-workers] (no subject)

[David Levine]

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