From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Eric Schulte" Subject: Re: using orgmode to send html mail? Date: Fri, 26 Mar 2010 08:53:09 -0600 Message-ID: <874ok33zje.fsf@gmail.com> 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> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NvAuq-00051O-9h for emacs-orgmode@gnu.org; Fri, 26 Mar 2010 10:53:40 -0400 Received: from [140.186.70.92] (port=39155 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NvAuf-0004wh-Et for emacs-orgmode@gnu.org; Fri, 26 Mar 2010 10:53:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NvAuY-0004HW-AU for emacs-orgmode@gnu.org; Fri, 26 Mar 2010 10:53:27 -0400 Received: from mail-px0-f179.google.com ([209.85.216.179]:58261) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NvAuQ-0004DH-Vv for emacs-orgmode@gnu.org; Fri, 26 Mar 2010 10:53:18 -0400 Received: by pxi9 with SMTP id 9so2091993pxi.6 for ; Fri, 26 Mar 2010 07:53:13 -0700 (PDT) In-Reply-To: <87vdckksnj.wl%dmaus@ictsoc.de> (David Maus's message of "Thu, 25 Mar 2010 22:17:36 +0100") 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: David Maus Cc: Dan Davison , emacs-orgmode@gnu.org --=-=-= Hi, --=-=-= Content-Type: multipart/alternative; boundary="==-=-=" --==-=-= So I believe inline LaTeX images are working in gnus, see here $\sum{\text{ric}}$ and immediately below $$ \frac{\sum_{n \in \text{daily tasks}}{n}} {\text{Emacs}} = \text{Org-mode} $$ This turned out to be fairly easy, and didn't require any encoding or explicit mime function calls. I've also re-structured the code so that it should be easy to apply the appropriate mime markup for WL and VM. There are now two mime-library dependent functions `org-mail-file' and `org-mail-multipart' each of which contains a `case' block for library-specific behavior, e.g. #+begin_src emacs-lisp (case org-mail-mime-library ('mml (format (concat " --==-=-= Content-Type: multipart/alternative; boundary="===-=-=" --===-=-= " "%s --===-=-= Content-Type: text/html %s --===-=-=-- --==-=-= plain html)) ('semi "?") ('vm "?")) #+end_src everything is available at http://github.com/eschulte/org-html-mail I'd love to hear feedback, suggestions, or expansion of the missing WL and VM portions of the two functions mentioned above. --==-=-= Content-Type: text/html

So I believe inline LaTeX images are working in gnus, see here
and immediately below




This turned out to be fairly easy, and didn't require any encoding or
explicit mime function calls.


I've also re-structured the code so that it should be easy to apply the
appropriate mime markup for WL and VM. There are now two mime-library
dependent functions `org-mail-file' and `org-mail-multipart' each of
which contains a `case' block for library-specific behavior, e.g.



(case org-mail-mime-library
  ('mml (format (concat "<#multipart type=alternative><#part type=text/plain>"
                        "%s<#part type=text/html>%s<#/multipart>\n")
                plain html))
  ('semi "?")
  ('vm "?"))
everything is available at http://github.com/eschulte/org-html-mail


I'd love to hear feedback, suggestions, or expansion of the missing WL
and VM portions of the two functions mentioned above.

--==-=-=-- --=-=-= Content-Type: image/png Content-ID: <_tmp_ltxpng_mail2517Uwd_bec399e15ff6f585494f84227a582a8056aca5a5.png> Content-Disposition: attachment; filename=mail2517Uwd_bec399e15ff6f585494f84227a582a8056aca5a5.png Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAANoAAAAoCAMAAACvmRT7AAAAM1BMVEX///8AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADxgEwMAAAAEHRSTlMA77vNEFR2IomZ Mt1Eq2ZsUGo9LgAABHRJREFUaAXdWAl26ygQBMQuYLj/aaeKxZaU2I6TeMnv9+JIgFAXvVVLCFnV kEXWWrX4d8RUewLj/ObmNPp3L0KNZ+WdOl//A1frugGRNjg3w3/00tX8RzW/rXap5faiH6+w3jpb lPvxRndtkOvjX+hS5AnacJdmP1+8C7efb/fZDkYUxnR4NrR4M+mb8OOKlz2greYz3A8c08tNxZez zyor3EI9t3LMrHE5BrBMQrinc4IvBPdmiQGMcoCmz4V/ALYHaK5iwitxGN4ezwOuwyUvsQHSX7iB xoEjtHwTWlnwmELI9f2e81v2alkVi21GCcMJoy9lxbVt4w4OSWhpRT1cu/XMoqwb89oaAofV/GrG DYB4vqWE/bseDDBuK7aJySkoJqnHiB/N1EZosBwNTMXbHww6NW2K9/mCJRi2xXFdv3kwhAvb6y1t dIvQhBXpPZnuCIcsXME0oq0dFusOKYVDamjSoPV5JxemUxtWHM24Gaue/G8TRJ35A56wFspNa05o GroSwrSaCGdXxnga804kzy0Cz2fcPAdTybuqmeUyZEW7RlpSML86RLsZET8dMsF6ASF0ghbXU06w VpQxb2EsnApjzYtx83Vo3lsbpi98/bG+0m6ZvnBxK0AmuHEu3D2PV0SYZwWubEtRxqnF4Y+BeC52 yC1uzBckHYPKp1yqvt/0F3/h1/WSzmj/jpgdtKs7WIbblRUziVxZct/USLhafm/nO6Bd1aukUxK5 uu6OSTvJSpgXdzyMpb8FzfhTpN2nwOXVJ5puqhFpkdGi5uhgEYAzONJSHcIiRfwwfJDximfg0PV7 rCFa803ieFmJx8xU1hwKohQVSBYmXdYbRHjDgSnN3sgwgVmm8MDzVUn4dsNYU5yfG+H+FZLntzQF /tVkD831NlJiMs9CRGhIYJEOS+oWyUyBtI22vqlNCTzKhP906Tg++V1Jgiit8W+Eurd4m15IE3BD xAbQNmix/tf+95ECydPIfb/X//puJ1iJVhnQTLGWwbRIKWGnz6ClHbTX4xAfHVLLXmp0a40HtFnj NOUIrbtfkd15abU+4t4ujzjJrKCXhnA6ZNqpubcaaAINavqXicw00tjWPI83sOBUQXuk+p7ok6qZ 6SUxF5yCLeaak1E1uLJUD9D4UtaImfVwXMmsb4MFNbotMcgavA/q5ueT23t9a0WktjrJnem+tdPH h3JPW+ka4/r41K+NkIxDbn+9+cYbBzTxKvdtNMOTjf+6NGhw+lFWf33/F27YoDU2cORvuhS0ZBRG LmoPuhm7bdpfqPWXXp2r9wuzKmsK+dmJv2X2pgxBErgiRWIiPlMiPvHecrbagb+1Npx9hCOtQ5ox bE1H+/remIZ2DRrsoeOB5AATmn3kTzO7K1Xl25G3a2fcoGFBQuu0o6bCwkpmA00LV9RkuNe2fJe5 CQ0JYw+t+SGgpXYhtC7kAOohafoxhzGgOQTVHlqkDb3E99TAtOjbtzDxfg3upWM5Ey0ljvytqFKc CjCTzaRtIHHFvkv5+x/gkSwYUikgMQAAAABJRU5ErkJggg== --=-=-= Content-Type: image/png Content-ID: <_tmp_ltxpng_mail2517Uwd_da7d4c60345e5ae9c5d477dbb9995ea627d66593.png> Content-Disposition: attachment; filename=mail2517Uwd_da7d4c60345e5ae9c5d477dbb9995ea627d66593.png Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAACkAAAASBAMAAAA08+qrAAAAMFBMVEX///8AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAv3aB7AAAAD3RSTlMA77vNEFR2IomZMt1E q2ZgJmI6AAAAy0lEQVQYGWNg/KSkpKQs/9+BARmwfgPx2PsTwIJsImCKgWH+AhCDXQFEMvAZgCkG Bu4NYMYpKBdKsf9F5UN57x9AGDyGy7YvEmFgm5YD4vN+h4gyLHyyi+ULQy/DQzB/N1S0voCB5Qv7 L4aTYP76BIhwPQNQlPULVI2zAzZRdagsWC3QBBaQKs4AZFGGSQwcIP4zqCCP/lWGtX8L2K6lAwW4 LoBFo6ByUMoJTLPDAgAqCrYLFmYwDbzCxsbG1v//F8AEIFpXgcFyFEEA5wE0N1bvAm4AAAAASUVO RK5CYII= --=-=-= David Maus writes: > Okay, took a look on the specs and attached is a memo on how an > implementation of org to MIME could be done. The MIME delimiters of > SEMI and mml are quite similar so there's already a generic function > that creates representation of a MIME message for both. > > I've published this memo on Worg, too, occupying some space in > > http://orgmode.org/worg/org-devel.php > I took a look at this page, but it wasn't entirely clear to me what the SEMI markup language should look like. As mentioned above, for now I've gone with `case' statements for each mime library, rather than an alist of format strings -- in the off chance that different libraries could require information in a different order. > > The tasks at hand would be: find the functions that attach a file in > mime-edit-mode and mml-mode and look who they can be utilized. > I think that the mime markup libraries should handle attaching image (including any encoding issues). For example in gnus with mml only the path to the image need be supplied. > > Best > -- David > Cheers -- Eric > > -- > OpenPGP... 0x99ADB83B5A4478E6 > Jabber.... dmjena@jabber.org > Email..... dmaus@ictsoc.de > > > Author: David Maus > Date: 2010-03-25 21:56:50 CET > > > Table of Contents > ================= > 1 Representing a MIME internet message > 2 MIME delimiters of SEMI and mml > 3 Generic function > 4 Open questions > 4.1 How to handle charset information? > 4.2 How to attach files? > 5 Quotes from the specs > 5.1 MIME multipart: Notion of structured, related body parts > 5.2 MIME multipart: order of entities inside a multipart > > > 1 Representing a MIME internet message > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > A MIME internet message consists of one or more MIME entities. Each > MIME entity is of a distinct type and subtype, has a body and > optional MIME headers related to it's content. > > A MIME entity is represented as a list: > > (TYPE SUBTYPE BODY CONT-HEAD) > > TYPE: Symbol of MIME media type (e.g. text, video, audio). > > SUBTYPE: Symbol of MIME media subtype (e.g. plain, html). > > BODY: String with entity body -or- list of other MIME entities. > > CONT-HEAD: List of cons with content related MIME header > fields. The name of the header field without the > prefix "Content-" is car, the value cdr. > > Example: > > > '(text html "

Headline

" ((disposition . inline))) > > For messages of type multipart the body consists of a list of one > or more MIME entities. > > '(multipart alternative > '((text plain "* Headline") > (text html "

headline

"))) > > 2 MIME delimiters of SEMI and mml > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > The MIME delimiters are defined in an association list with a > symbol of the library's name as key and delimiter format strings as > values. For each library there are three formatstrings. > > (SYMBOL DELIM-SINGLE DELIM-SINGLE-CONT DELIM-MULTI) > > DELIM-SINGLE: Denoting a single MIME entity. > > Strings are passed in this order: > > 1. type > > 2. subtype > > 3. content header > > 4. body > > DELIM-SINGLE-CONT: Format of content header strings. > > Strings are passed in this order: > > 1. header field name > > 2. header field value > > DELIM-MULTI: Enclosing parts of a multipart entity. > > Strings are passed in this order: > > 1. subtype > > 2. body > > 3. subtype > > > (setq org-mail-htmlize-mime-delimiter-alist > '((semi "\n- -[%s/%s%s]\n%s" "\ncontent-%s: %s" "\n- -<<%s>>-{\n%s\n- -}-<<%s>>") > (mml "\n<#part type=\"%s/%s\"%s>\n%s" " %s=\"%s\"" "\n<#multipart type=\"%s\">\n%s\n<#/multipart>"))) > > 3 Generic function > ~~~~~~~~~~~~~~~~~~~ > > This generic function returns a string representation with MIME > delimiters depending on the variable =org-mail-htmlize-mime-lib=. > > > (setq org-mail-htmlize-mime-lib 'semi) > > > (defun org-mail-htmlize-mime-entity (type subtype body > &optional cont-head) > "Return string representation of MIME entity. > > TYPE is the type of entity body. > SUBTYPE is the subtype of body. > BODY is the body of the entity. Either a string with the body > content or a list with one ore more MIME entities. > Optional argument CONT-HEAD is a list of cons with content > specific headers, name in car and value in cdr." > (let ((delimlst (assoc org-mail-htmlize-mime-lib > org-mail-htmlize-mime-delimiter-alist))) > (if (eq type 'multipart) > (format (nth 3 delimlst) subtype > (mapconcat '(lambda (b) > (apply 'org-mail-htmlize-mime-entity > (car b) (cadr b) (cddr b))) > body "") > subtype) > (format (nth 1 delimlst) > type subtype > (mapconcat '(lambda (h) > (format (nth 2 delimlst) (car h) (cdr h))) > cont-head "") > body)))) > > 4 Open questions > ~~~~~~~~~~~~~~~~~ > > 4.1 How to handle charset information? > ======================================= > > 4.2 How to attach files? > ========================= > > The generic function expects BODY either be a string or a list. > Attaching binary file (image, etc.) requires to encode it so the > message will pass the message system. So we /might/ use kind of a > encoder (e.g. base64) on our own. > > Or, what seems a cleaner solution: Use attachment function of the > respective MIME mode. To achive this: Introduce third possibility > for BODY: A cons with the filename in car and symbol of the > function in cdr. > > (FILENAME . FUNCTION) > > > '(image jpeg ("/path/to/image" . org-mail-htmlize-add-attachment)) > > The function =org-mail-htmlize-add-attachment= is called with file > name as argument and calls the appropriate function depending on > =org-mail-htmlize-mime-lib= and returns a string > > - with the encoded body > > -or- > > - the complete MIME entity > > Side effect: The user might be prompted for attachment settings > (e.g. encoding). But, on the other hand: We delegate the job of > creating the attachment to the library that is responsible for > mime. > > 5 Quotes from the specs > ~~~~~~~~~~~~~~~~~~~~~~~~ > > 5.1 MIME multipart: Notion of structured, related body parts > ============================================================= > > - [RFC2046, 5.1.1] > > ORG-BLOCKQUOTE-START > NOTE: Conspicuously missing from the "multipart" type is a notion of > structured, related body parts. It is recommended that those wishing > to provide more structured or integrated multipart messaging > facilities should define subtypes of multipart that are syntactically > identical but define relationships between the various parts. For > example, subtypes of multipart could be defined that include a > distinguished part which in turn is used to specify the relationships > between the other parts, probably referring to them by their > Content-ID field. Old implementations will not recognize the new > subtype if this approach is used, but will treat it as > multipart/mixed and will thus be able to show the user the parts that > are recognized. > ORG-BLOCKQUOTE-END > > [RFC2046, 5.1.1]: http://tools.ietf.org/html/rfc2046.html#section-5.1.1 > > 5.2 MIME multipart: order of entities inside a multipart > ========================================================= > > - [RFC2046, 5.1.3] > > ORG-BLOCKQUOTE-START > 5.1.3. Mixed Subtype > > The "mixed" subtype of "multipart" is intended for use when the body > parts are independent and need to be bundled in a particular order. > Any "multipart" subtypes that an implementation does not recognize > must be treated as being of subtype "mixed". > > ORG-BLOCKQUOTE-END > > - [RFC2046, 5.1.4] > > ORG-BLOCKQUOTE-START > 5.1.4. Alternative Subtype > > The "multipart/alternative" type is syntactically identical to > "multipart/mixed", but the semantics are different. In particular, > each of the body parts is an "alternative" version of the same > information. > > Systems should recognize that the content of the various parts are > interchangeable. Systems should choose the "best" type based on the > local environment and references, in some cases even through user > interaction. As with "multipart/mixed", the order of body parts is > significant. In this case, the alternatives appear in an order of > increasing faithfulness to the original content. In general, the > best choice is the LAST part of a type supported by the recipient > system's local environment. > ORG-BLOCKQUOTE-END > > ORG-BLOCKQUOTE-START > In general, user agents that compose "multipart/alternative" entities > must place the body parts in increasing order of preference, that is, > with the preferred format last. For fancy text, the sending user > agent should put the plainest format first and the richest format > last. Receiving user agents should pick and display the last format > they are capable of displaying. In the case where one of the > alternatives is itself of type "multipart" and contains unrecognized > sub-parts, the user agent may choose either to show that alternative, > an earlier alternative, or both. > ORG-BLOCKQUOTE-END > > [RFC2046, 5.1.3]: http://tools.ietf.org/html/rfc2046.html#section-5.1.3 > [RFC2046, 5.1.4]: http://tools.ietf.org/html/rfc2046.html#section-5.1.4 --=-=-= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --=-=-=--