Re: [Nmh-workers] New mhbuild directives

[Ken Hornstein]

>> Sigh.  I didn't say that.
>
>Yes you did! You explicitly called out an in-code hardwired table.

In this message:

  http://lists.nongnu.org/archive/html/nmh-workers/2014-05/msg00156.html

I referred to the current implementation that special-cases text/calendar.
I also mentioned that I disliked it; I thought it was obvious from my
message that the special case should be removed.  Moving on ...

>> - Implement a new "Inline" header. inline" command at the WhatNow
>> - Implement a new "prompt.
>
>How can an inline header specify where to inline the content?  The point
>of inline is to display the content in the context of the location of
>the inlined MIME part.  I.e. right *here* where I invoke it.

I know you quoted the relevant part of RFC 2183, but notice that what
it really says is that items marked as "inline" should be displayed
immediately and in the order in which they occured.

It should be obvious that a hypothetical "Inline" header would append such
parts to the end of the message.  In practice, that's what I care about.
For example, I don't really care that a text/calendar item is displayed
at a particular spot in my message; what I do care about is that the
receiving MUA processes the calendar request contained therein, and for
some MUAs that only happens if the disposition is inline.

>But the MIME authors allowed for mixed MIME parts throughout the
>message, some with inline, some without.  Might they not have had a
>reason for doing things that way?

No one is saying that we shouldn't support that capability, and nothing
about this would remove that; mhbuild directives still exist, of course.
You can create whatever MIME content you want.  I'm just trying to make
the most common case easier.

Now, regarding the #attach/#inline mhbuild directives ... I'm not against
them.  I'm just not personally interested in writing the code (which will
end up being more complicated than I would like, given the way that
directive processing hooks into get_ctinfo()).  Someone else is free to
do that.

--Ken