Re: [Nmh-workers] (no subject)

[Robert Elz]

    Date:        Wed, 20 Aug 2014 09:46:18 -0400
    From:        David Levine <address@hidden>
    Message-ID:  <address@hidden>

  | 1) I use "preferred" the same way that RFC 2046 §5.1.4 uses it:

OK, but that's (as you said) from the sender's perspective.   When I am
using these tools, I'm not the server, and it is my preference that should
matter.  Of course, if I have no preference, then using the sender's is
fine, but in this case, I do.

  | 3) It's not up to mhlist to delete alternatives.

Of course .. that was a (kind of, and fairly weak) attempt at humour...

  | Boundaries are at a low level, MIME structure is at a higher level.

The boundaries define the MIME structure (along with the associated headers)
so they're really at the same level - forming the content of them might be
a lower level but that's not relevant here.

  | mhlist doesn't present the boundaries, even with -verbose.

No, but it uses them.

  | And, my whole point:  because scripts rely on MH/nmh commands,
  | don't change those commands (when not necessary).

I agree with that principle, but here it really is necessary - the
current behaviour can't really be justified as anything other than a bug.
That it was recently documented doesn't change that characterisation.

  | If mhlist ordered multipart/alternative parts in increasing
  | order of preference, I'd have to iterate from the back.

You could, but I wouldn't - better to simply iterate over all the
alternatives, and remember which one is the one you want to display.

There are not going to be so many that optimising by exiting the
loop early is going to be of any measurable benefit, and looking at
all the alternatives makes it easy to allow the user to set their own
preference to override the sender's (which seems to be a much requested
feature - hard to implement at the minute (I assume) because the code is
not looking at all the alternatives).

  | mhlist does show what is actually in the message.  Nothing is
  | lost with the presentation.

No it doesn't, for a message I have ...

 msg part  type/subtype              size description                         
  47       multipart/alternative      27K
     1     text/html                  10K Message in HTML form                
     2     text/plain                9984 Message in clear text               

but when I look inside the message, the first alternative is text/plain and
the second is text/html - mhlist is lying to me.   If I were to write a
script (not using mhstore, but sed) to save the text/plain part, I'd
get the html variant instead.   That's just broken.

kre