Re: org-mime-htmlize: visual representation (thunderbird)

[Uwe Brauer <oub@mat.ucm.es>]

>> On Wed, 11 Apr 2012 00:23:54 -0400, Eric Schulte <eric.schulte@gmx.com> wrote:

   > Uwe Brauer <oub@mat.ucm.es> writes:
   >> 
   >> Uwe 
   >> 

   > Hi Uwe,

   > Thanks for sending along this helpful review.  I've just pushed two
   > changes to org-mime so that it now (1) wraps html and images in a
   > multipart/related mime structure and (2) marks images as "disposition
   > inline" so that they don't show up as attachments.

Hi Eric, 

Thanks for your efforts. I have good and bad news. The bad
news is your changes make things worse in Thunderbird, for
reasons I don't understand the header of the resulting
messages reads:
Content-type: text/plain; charset=us-ascii
which is wrong and now png are displayed!

Which brings me to the good news. After I wrote to you I
received a message from  the TB developers  which emphasised
that, besides the information I have gave you, the main
point is the header, which should be 

  Content-type: multipart/related; boundary="=-=-="
 and the thunderbird developers insist that this is the 
 RFC 2387 standard.

Gnus actually generate  via the mml-generate-mime function
the header 
  Content-type: multipart/mixed; boundary="=-=-="
which is wrong.

I brought up the issue in the gnus mailing list and the
developers agreed that in the case of a html message with
png the Content-type should follow the RFC standard.

I checked this explicitly: your old code but with a different
mml-generate-mime function generates a message which is
correctly displayed in thunderbird and GMail and Ipod for
that manner. 

BTW I don't know how this issue, of the Content-type in the
header,  is treated in VM or Wanderlust.

Now the question is how to proceed:
I had the idea of introducing a new variable mml-mime-use-related and wrap it
into the mml-generate-mime code. Then org-mime-htmlize
should set this variable to t, and later a different
function should be added to the mail-send-hook setting the
variable to nil again.

Lars didn't like the idea and came up with a different
implementation. However I don't see how to use it easily. So
I include both solutions and let you decide which fits best
for org-mime-htmlize.
But as it is now you should undo your recent changes because
even with  the *new* mml-generate-mime function and your
*new* code the resulting mail is not displayed correctly in
TB.

I have now added lars and the ding mailing list to the CC.

Regards

Uwe 

My solution:
,----
| (defvar mml-mime-use-related t
| "*Variable to control whether to use `multipart/mixed' or `multipart/related'.")
| 
| (defun mml-generate-mime ()
|   "Generate a MIME message based on the current MML document."
|   (let ((cont (mml-parse))
| 		(mml-multipart-number mml-multipart-number))
|     (if (not cont)
| 		nil
|       (mm-with-multibyte-buffer
| 		(if (and (consp (car cont))
| 				 (= (length cont) 1))
| 			(mml-generate-mime-1 (car cont))
| 		  (if mml-mime-use-related
| 			  (mml-generate-mime-1 (nconc (list 'multipart '(type . "related"))
| 										  cont))
| 			(mml-generate-mime-1 (nconc (list 'multipart '(type . "mixed"))
| 										cont)))
| 	(buffer-string))))))
`----


Lars solution 

,----
| (defun mml-generate-mime (&optional multipart-type)
|   "Generate a MIME message based on the current MML document.
| MULTIPART-TYPE defaults to \"mixed\", but can also
| be \"related\" or \"alternate\"."
|   (let ((cont (mml-parse))
| 	(mml-multipart-number mml-multipart-number)
| 	(options message-options))
|     (if (not cont)
| 	nil
|       (prog1
| 	  (mm-with-multibyte-buffer
| 	    (setq message-options options)
| 	    (if (and (consp (car cont))
| 		     (= (length cont) 1))
| 		(mml-generate-mime-1 (car cont))
| 	      (mml-generate-mime-1
| 	       (nconc (list 'multipart (cons 'type (or multipart-type "mixed")))
| 		      cont)))
| 	    (setq options message-options)
| 	    (buffer-string))
| 	(setq message-options options)))))
`----