From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Davison Subject: Re: [CONTRIB?] using orgmode to send html mail? Date: Wed, 31 Mar 2010 17:37:48 -0400 Message-ID: <878w98w4sz.fsf@stats.ox.ac.uk> References: <878w9krtyn.wl%dmaus@ictsoc.de> <871vfa24qo.fsf@gmail.com> <87pr2uww2d.fsf@columbia.edu> <87tys5zrwm.fsf@gmail.com> <87sk7pzk02.fsf@stats.ox.ac.uk> <87tys5r3q6.fsf@gmail.com> <87ocid7cuj.wl%dmaus@ictsoc.de> <874ok5qxp9.fsf@gmail.com> <87vdckksnj.wl%dmaus@ictsoc.de> <874ok33zje.fsf@gmail.com> <87zl1vf4ru.wl%dmaus@ictsoc.de> <874ok311t9.fsf@gmail.com> <87y6h85pid.fsf_-_@gmail.com> <87fx3g1cld.fsf@stats.ox.ac.uk> <87eij05had.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nx5bo-0004gw-Le for emacs-orgmode@gnu.org; Wed, 31 Mar 2010 17:37:56 -0400 Received: from [140.186.70.92] (port=36934 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nx5bm-0004gE-UW for emacs-orgmode@gnu.org; Wed, 31 Mar 2010 17:37:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nx5bk-0001V4-N8 for emacs-orgmode@gnu.org; Wed, 31 Mar 2010 17:37:54 -0400 Received: from markov.stats.ox.ac.uk ([163.1.210.1]:44135) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nx5bk-0001UO-Eg for emacs-orgmode@gnu.org; Wed, 31 Mar 2010 17:37:52 -0400 In-Reply-To: <87eij05had.fsf@gmail.com> (Eric Schulte's message of "Wed, 31 Mar 2010 15:10:18 -0600") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Eric Schulte Cc: emacs-orgmode@gnu.org "Eric Schulte" writes: > Dan Davison writes: > >> "Eric Schulte" writes: >> >>> Hi, >>> >>> I've been using the code currently located at [1] for sending HTML email >>> [2] for a little while now, and it is working very well. >> >> Hi Eric, >> >> I just tried pasting content from an org file into a message-mode buffer >> and calling org-mail-htmlize on the region, and sending the resulting >> message to gmail. It worked very nicely, with two drawbacks: >> >> 1. The content contained links to an image like [[file:file.png][]]. I >> had to manually copy the image to /tmp in order for it to be found on >> sending. >> > > As the mail composition buffer doesn't really live on the file system > relative paths will not work. I believe specifying an absolute path to > the image would work, or as you mentioned during export the mail buffer > is written to the /tmp directory, so basing relative paths there will > also work. I think this behavior is sufficient, and can't think of any > good alternative. As I understand it the code you've written is designed to be called in a message-mode buffer with orgstruct-mode in force. Would it make sense to also include in your package a complementary function, that one calls in an org-mode buffer? I envisage this generating the HTML, forming the multipart email contents, and then saving it to the kill ring, so that it can be pasted into an email. This function would have access to the directory-name and so should be able to resolve relative paths. Also, there might be some other advantages -- for example when exporting just a region or subtree, buffer-wide properties such as #+TITLE and #+AUTHOR are picked up by the org exporter and packaged into the HTML. In other words, can I use your machinery to package up the HTML generated by Org's C-e dispatcher into an appropriately-constructed email? > > Note that images generated during export to html (e.g. latex images, > babel images, etc...) will be resolved correctly. > >> >> 2. The TODO keywords and timestamps lacked their org-mode >>fontification. >> > > Ah yes, sites like gmail are careful not to allow page-wide css in HTML > mail. All css must be embedded into specific html elements (e.g. 
 style="...">).  This is reasonable on their parts as a malicious email
> could destroy the rendering of the web interface.

I see.

>
>>
>> Is there a different procedure I should use to do what I'm trying to
>>do, or are these tweaks that could be made to your code? I have not
>>attempted to follow the technical aspects of this thread so I may well
>>be misunderstanding stuff here.
>>
>
> There is a hook provided in the supplied code, currently called
> `org-mail-html-hook' which you can use to doctor the final html.  For
> example I use the following to force a dark background on all my code
> blocks.
>
> ;; example hook, for setting a dark background in 
 elements
> (defun org-mail-change-pre-colors (foreground background)
>   "Set new default htlm colors for 
 elements in exported html mail."
>   (while (re-search-forward "     (replace-match
>      (format "
              foreground background))))
>
> ;; example addition to `org-mail-html-hook' adding a dark background
> ;; color to 
 elements
> (add-hook 'org-mail-html-hook
>           (lambda ()
>             (org-mail-change-pre-colors "#E6E1DC" "#232323")))
>
> An extension of this could be used to add missing CSS elements where
> required.

OK, thanks for that.

Dan

>
> Best -- Eric
>
>>
>> Thanks!
>>
>> Dan
>>
>>
>>
>>>
>>> I wonder if this should be included in the contrib directory of
>>> Org-mode?  Also, since it currently only supports gnus (it should be
>>> very easy to extend to WL and VM, but I don't have access to these other
>>> mailers for testing/verification) maybe it should be sent to the gnus
>>> mailing list instead?
>>>
>>> Cheers -- Eric
>>>
>>> Footnotes: 
>>> [1]  http://github.com/eschulte/org-html-mail
>>>
>>> [2] In defense of sending html mail I should mention that I've only been
>>>     using it to send tables and latex images to people who I know don't
>>>     have access to a true fixed-width font email client.  In addition
>>>     the code presents html as one multipart/alternative with the full
>>>     org-mode plain text presented as a text alternative, so those who
>>>     care and who have control over their email clients can opt to view
>>>     the text portion and ignore the html.  In gnus this is possible with
>>>     
>>>     (setq mm-discouraged-alternatives '("text/html" "text/richtext"))
>>>
>>>
>>> _______________________________________________
>>> Emacs-orgmode mailing list
>>> Please use `Reply All' to send replies to the list.
>>> Emacs-orgmode@gnu.org
>>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode