Re: using orgmode to send html mail?

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

David Maus <dmaus@ictsoc.de> writes:

> Eric Schulte wrote:
>>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.
>
> Yes, somehow we have to hook or defadvice before mml/semi translates
> the message buffer to real MIME.  I'm not sure about the defadive: We
> would change functioallity of the translating function globally.
>

I've done this previously.  Luckily orgstruct-mode already intercepts
C-c C-c (which is used to send mail in gnus) and it is not difficult to
check for a prefix argument at that stage (before any mime encoding) and
optionally run an html conversion there.

>
>>>
>>> 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.
>>>
>
>>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.
>
> Funny thing: It's basically the same operation, only difference is in
> the original content's source:
>
>     +------------+
>     | Org buffer |--+
>     +------------+  |    +------------+   +----------------+
>                     +--->| MIME setup |-->| Message buffer |
> +----------------+  |    +------------+   +----------------+
> | Message buffer |--+
> +----------------+
>

Yup, I looks like it will just be a question of how to position the
resulting message buffer so that all of the references resolve.

Thanks -- Eric

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