Re: using orgmode to send html mail?

["Eric Schulte" <schulte.eric@gmail.com>]

David Maus <dmaus@ictsoc.de> writes:

> Eric Schulte wrote:
>>>
>>> Thinking functional this might be the first function of
>>> org-mail-htmlize[1]: Create a html representation of message body if
>>> necessary or appropriate.
>>>
>
>>Oh, so this would be a slightly different issue,
>
>>So this function could be run *every* time an email is sent.  I agree
>>that in those cases running on the entire message would be the right way
>>to go.
>
> Right, this would be nice for people who are obliged to send out html
> messages.  If this is turned on org-mime should display the string
> "HTML" in the mode line.  In the WL it's done this way:
>
> ,----
> | (defun dmj/wl-send-html-message-draft-init ()
> |   "Create buffer local settings for maybe sending html message."
> |   (unless (boundp 'dmj/wl-send-html-message-toggled-p)
> |     (setq dmj/wl-send-html-message-toggled-p nil))
> |   (make-variable-buffer-local 'dmj/wl-send-html-message-toggled-p)
> |   (add-to-list 'global-mode-string
> |                '(:eval (if (eq major-mode 'wl-draft-mode)
> |                            dmj/wl-send-html-message-toggled-p))))
> `----
>
> This function is hooked into mime-edit mode and set's a buffer local
> variable that indicates "html message mode" and is displayed in the
> mode line.
>

Another option here is to add a defadvice to the actual sending command
(C-c C-c in gnus) such that if the command is called with a prefix
argument, then `org-mime-htmlize' is run on the entire message before
mail delivery.  To me this seems like a simpler solution than the above.

>
>>>
>>> 2/
>>>
>>> The second function: Attach external files that are referenced in the
>>> message.  This might be useful even if you don't send out html
>>> messages: All external files are stashed into a multipart/mixed
>>> container along with a Content-Id: header field.
>>>
>>> Than all references are changed accordingly to point to the attached
>>> files:
>>>
>>>   - for html use src/href with the cid: prefix
>>>
>>>   - for text: good question.  Maybe replace occurences of the file
>>>     with a customizable string saying: "see attached file foo.bar".
>>>
>
>>I'm not sure I understand, I'm currently happy with my mail agent's
>>method of attaching files to email, what else would this use of the
>>function add aside from a new attachment syntax.
>
> What I meant was: Suppose you write a document in Org with references
> to external files (images etc.).  If finished you'd like this document
> to a fellow by mail including all external files.  So this function
> collects all these files, and maybe converts the message body to html,
> fires up Gnus/WL with a new message and inserts something like
>
> < #multipart type="alternate">
> < #part type="text/plain"> ...plain text body...
> < #part type="text/html"> ...html body...
> < #/multipart>
> < #multipart type="mixed">
> < #part type="image/png"> image1.png
> < #part type="image/png"> image2.png
>   ...
> < #/multipart>
>
> That is: The original document including all external files -- and all
> references in the original file are replaced by references to the
> attachments.
>

Ah, this sounds similar to the extension proposed by Dan and seconded by
a couple of others on the list.  It seems like the big question here is
how to convey all of the required mime information from the org-mode
buffer to the message body.

If I'm understanding correctly both you and Dan seem to be in favor of
exporting to mime and packaging up the raw mime information from the
org-mode buffer.  I'm leaning towards thinking that it may be easier to
simply bring the mail buffer to the org-mode file by saving it to a
temporary location alongside the org-mode file (so all links resolve).
It will probably take some experimentation to find out which approach is
more feasible/natural.

>
> Original
> ,----
> | ...
> | As you can see in [[file:figure1.png][Figure 1]], cats
> | *are* the cutest animals on earth.
> | ...
> `----
>
> "figure1.png" will be attached and the reference adjusted to the
> attachment.
>
> HTML
> ,----
> | As you can see in <a href="cid:id-of-figure1.png" title="Figure 1">Figure 1</a>,
> | cats <b>are</b> the cutest animals on earth.
> `----
>
> Plain
>
> ,----
> | As you can see in Figure 1 (see attached file: figure1.png), cats
> | *are* the cutest animals on earth.
> `----
>
>>> 4/
>>>
>>> Detecting the plain text body should not just stop on end of buffer
>>> but also on the first occurence of a MIME delimiter: Maybe the user
>>> already added a attachment.
>>>
>
>>Good point, one open question here is how to treat that mime border, I'm
>>thinking it may be best to simply stash it in a
>
>>#+BEGIN_HTML
>>original mime content
>>#+END_HTML
>
>>block, so that it survives the Org-mode export unscathed, however maybe
>>it's simpler just to end the html alternative part at the first mime
>>border.
>
> Yes, it is simpler.  Simply search for the end of the message body
> with the condition: either eobp or MIME delimiter.
>
> For example when in mml (line 92ff in org-mime.el):
>
> ,----
> | (html-end (or (and region-p (region-end))
> | 	      (if (not (re-search-forward "^<#part\\|^<#multipart" nil t))
> | 		  (point-max)
> |		;; one line up
> | 		(end-of-line 0)
> | 		(point))))
> `----
>
> With this you can even catch the signature that is separate by "--
> \n".  If re-search-forward finds an attachment the body ends right
> before.  Small glitch: This code assumes MIME delimiters start at the
> beginning of a line ("^").
>

Agreed, this approach is simpler to implement however if the other
approach works I think it may be easier to use.  Again this question may
have to be hammered out on the forge of trial and error.

Thanks for the feedback.  There is clearly some more work do be done on
this front, but it is sounding like it will be a useful product once
complete.

Am I right in assuming that the current version is now working for WL?

Best -- Eric

>
>  -- David
>
> --
> OpenPGP... 0x99ADB83B5A4478E6
> Jabber.... dmjena@jabber.org
> Email..... dmaus@ictsoc.de