From: "Eric Schulte" <schulte.eric@gmail.com>
To: David Maus <dmaus@ictsoc.de>
Cc: Dan Davison <davison@stats.ox.ac.uk>, emacs-orgmode@gnu.org
Subject: Re: using orgmode to send html mail?
Date: Fri, 26 Mar 2010 08:53:09 -0600 [thread overview]
Message-ID: <874ok33zje.fsf@gmail.com> (raw)
In-Reply-To: <87vdckksnj.wl%dmaus@ictsoc.de> (David Maus's message of "Thu, 25 Mar 2010 22:17:36 +0100")
[-- 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
next prev parent reply other threads:[~2010-03-26 14:53 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-22 2:34 using orgmode to send html mail? Matt Price
2010-03-22 15:44 ` Matt Price
2010-03-22 20:18 ` David Maus
2010-03-23 19:54 ` Eric Schulte
2010-03-23 21:46 ` Xiao-Yong Jin
2010-03-24 15:00 ` Eric Schulte
2010-03-24 17:50 ` Dan Davison
2010-03-24 18:01 ` Eric Schulte
2010-03-24 19:12 ` David Maus
2010-03-24 20:19 ` Eric Schulte
2010-03-25 21:17 ` David Maus
2010-03-26 14:53 ` Eric Schulte [this message]
2010-03-26 16:04 ` David Maus
2010-03-26 16:32 ` Eric Schulte
2010-03-31 18:12 ` [CONTRIB?] " Eric Schulte
2010-03-31 20:05 ` Dan Davison
2010-03-31 21:10 ` Eric Schulte
2010-03-31 21:37 ` Dan Davison
2010-04-01 14:22 ` Eric Schulte
2010-04-05 5:39 ` Eric Schulte
2010-04-05 6:49 ` Carsten Dominik
2010-04-05 15:31 ` Eric Schulte
2010-04-09 16:41 ` [ANN] org-mime -- " Eric Schulte
2010-04-09 17:41 ` Matt Price
2010-04-09 19:11 ` Eric Schulte
2010-04-09 19:22 ` David Maus
2010-04-09 20:34 ` Eric Schulte
2010-04-12 13:37 ` Andrew Hyatt
2010-04-12 17:22 ` Eric Schulte
2010-04-13 1:31 ` Andrew Hyatt
2010-04-14 0:57 ` Eric Schulte
2010-04-14 1:57 ` Andrew Hyatt
2010-04-14 14:59 ` Eric Schulte
2010-04-14 18:00 ` Andrew Hyatt
2010-04-14 19:26 ` Bernt Hansen
2010-04-14 8:39 ` Eric S Fraga
2010-04-14 15:12 ` Eric Schulte
2010-04-14 19:38 ` Eric S Fraga
2010-04-15 2:49 ` Eric Schulte
2010-04-15 15:47 ` Eric Schulte
2010-04-13 23:03 ` Eric S Fraga
2010-04-14 1:22 ` Eric Schulte
2010-04-05 13:54 ` [CONTRIB?] " Dan Davison
2010-04-05 14:50 ` David Maus
2010-04-05 14:53 ` Dan Davison
2010-04-05 15:30 ` Eric Schulte
2010-04-01 17:37 ` Sivaram Neelakantan
2010-04-01 17:45 ` Sivaram Neelakantan
2010-03-31 20:37 ` David Maus
2010-03-31 22:03 ` Eric Schulte
2010-04-02 7:04 ` David Maus
2010-04-02 23:01 ` Eric Schulte
2010-04-03 9:19 ` David Maus
2010-04-04 17:52 ` Eric Schulte
2010-04-01 7:53 ` Vagn Johansen
2010-04-02 6:34 ` David Maus
2010-04-02 14:57 ` Dan Davison
2010-04-02 17:25 ` David Maus
2010-04-02 21:10 ` Eric Schulte
2010-04-03 9:00 ` David Maus
2010-04-03 12:03 ` David Maus
2010-04-04 2:41 ` Eric Schulte
2010-04-04 10:00 ` David Maus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874ok33zje.fsf@gmail.com \
--to=schulte.eric@gmail.com \
--cc=davison@stats.ox.ac.uk \
--cc=dmaus@ictsoc.de \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.