Re: using orgmode to send html mail?

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

[-- Attachment #1: Type: text/plain, Size: 5 bytes --]

Hi,


[-- Attachment #2.1: Type: text/plain, Size: 647 bytes --]

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 "

[-- Attachment #2.2.1: Type: text/plain, Size: 31 bytes --]

"
                          "%s

[-- Attachment #2.2.2: Type: text/html, Size: 2 bytes --]

[-- Attachment #2.3: Type: text/plain, Size: 267 bytes --]

                  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.

[-- Attachment #2.4: Type: text/html, Size: 1888 bytes --]

[-- Attachment #3: mail2517Uwd_bec399e15ff6f585494f84227a582a8056aca5a5.png --]
[-- Type: image/png, Size: 1288 bytes --]

[-- Attachment #4: mail2517Uwd_da7d4c60345e5ae9c5d477dbb9995ea627d66593.png --]
[-- Type: image/png, Size: 347 bytes --]

[-- Attachment #5: Type: text/plain, Size: 9962 bytes --]


David Maus <dmaus@ictsoc.de> 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 <dmaus@ictsoc.de>
> 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 "<h1>Headline</h1>" ((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 "<h1>headline</h1>")))
>
> 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

[-- Attachment #6: Type: text/plain, Size: 201 bytes --]

_______________________________________________
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