Re: [Nmh-workers] (no subject)

[Robert Elz]

    Date:        Tue, 19 Aug 2014 22:59:39 -0400
    From:        David Levine <address@hidden>
    Message-ID:  <address@hidden>

  | multipart/alternative IS different than any other content.

All the different content types are different in some way or other,
that's why they have different names...

  | The question is how mhlist/mhstore should present the part ordering
  | to the user.

I cannot really see how it is possible to rationally argue for anything
different than the order the parts appear in the message being the same
order they're listed (unless the user expressly has configured things to do
something different).   I had no idea that it was different (before this
discussion) - but then again, I don't use mhlist, mhstore or mhshow,
I mostly look at mime messages with exmh (which presents the alternatives in
the order they appear in the message) or with vi (wrapped in scripts/sh
functions which give it mh type arg conventions).

  | It makes sense to me to list the most preferred
  | part first as part 1, the next second as part 2, and so on.

In that case, text/plain would be first, text/html somewhere near last,
and application/msword deleted completely...

  | The parts are stored in reverse order in the message to make
  | them easier to view with non-MIME-conformant viewers.

That's the rationale for building messages with alternatives in the
order they are built, yes.

  | That is irrelevant to a user of mhlist/mhstore.  Why expose it?

Because (like all of MH) more than the MH (nmh) comands get used to
process messages, and commands that are just sh scripts, that look
for the boundaries, and count them, don't know about some fancy
reordering that mhlist is doing because it thinks we prefer it that
way (which we quite possibly don't in any case).

Even with reversing, you cannot just blindly assume that the first alternative
listed is going to be the html variant (it might be in many messages, but
there's no guarantee) - you have to look at a listing of the message
structure and pick the part that you want to view, or store - given
that, does it really make a difference if what you store is 1.3 rather
than 1.1 (and every now and again it happens to be 1.2) ?

In this, I totally agree with Ken, presenting anything to the user other
than what is actually in the message is just perverted.

Of course, I also agree (with everyone I think) that the ordering used
should be consistent, what is part 1.2 for one command must be 1.2 for
every command that understands this terminology.

kre