Lyndon wrote: > 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 don't read that from RFC 2183, just that inline means "intended to be displayed automatically upon display of the message" and "presented in the order in which they occur". So, it makes sense to me that inline text/calendar parts are automatically fed directly to a calendar program. I don't appreciate why gmail handles message/rfc822 attachments the way it does or doesn't. Even if we could get it "fixed", I suspect it won't be the last time we run into something similar. Back to the "Attach and disposition" subject, I don't want to lose sight of this: # it's a shame to have to foist the decision as to which to use # (Attach or Inline) onto the user. I, for one, would appreciate if nmh captured the knowledge that message/rfc822 parts should be sent inline to gmail. I'm not sure how other than based on MIME type. I don't send message/rfc822 often and would be fine with defaulting it to inline, but I don't know how others feel about that. Ken, when you first mentioned "a more generic mechanism", I was thinking along the lines of "mhbuild-disposition-<type>/<subtype>: inline" profile entries. mhn.defaults could provide those for text/calendar and possibly message/rfc822. Users could override as they wish in their profile. Forcing every nmh user to learn all the exceptions, and remember them every time they Attach:, is as user unfriendly as we could get. David _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
