Support via Liberapay

Ongoing Development of Org Additions?

Some org-mode related project currently being developed in worg.

Org Collector

Located in the contrib/lisp/ directory of org-mode.

A utility for collecting properties from the headers in an org file, running the properties through arbitrary elisp functions, and presenting the results in a table.

The functionality of this tool is similar to the functionality of info:org:Capturing column view, but this has support for processing prior to the generation of the table.

Here is a simple example application of this utility.

Example Data

  • run1
  • run2
  • run3
  • run4

MEMO org-mail-htmlize: Create MIME messages based on Org

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 its content.

A MIME entity is represented as a list:


Symbol of MIME media type (e.g. text, video, audio).
Symbol of MIME media subtype (e.g. plain, html).
String with entity body -or- list of other MIME entities.
List of cons with content related MIME header fields. The name of the header field without the prefix “Content-” is car, the value cdr.


'(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>")))

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.



Denoting a single MIME entity.

Strings are passed in this order:

  1. type
  2. subtype
  3. content header
  4. body

Format of content header strings.

Strings are passed in this order:

  1. header field name
  2. header field value

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>")))

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
    (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 "")
      (format (nth 1 delimlst)
              type subtype
              (mapconcat (lambda (h)
                            (format (nth 2 delimlst) (car h) (cdr h)))
                         cont-head "")

Open questions

How to handle charset information?

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.


'(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


  • 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.

Quotes from the specs

MIME multipart: Notion of structured, related body parts

  • RFC2046, 5.1.1

    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.

MIME multipart: order of entities inside a multipart

  • RFC2046, 5.1.3

    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”.

  • RFC2046, 5.1.4

    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.

    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 mode issue tracking library

A collection of helper functions to maintain the Issue file from within Wanderlust and (partly) Gnus.

You can download a current version of this file here.

Currently following commands are provided:


File a new issue for current message

Creates a new TODO in ’org-issue-issue-file’ below the headline “New Issues” with keyword NEW. If customization variable ’org-issue-message-flag’ is non-nil and flagging messages is supported, the message of this issue is flagged.

Close issue of current message.
Tag issue of current message.

Update message flag according to issue file.

If the issue for current message is closed, the message flag is removed.

An Org mode web link pointing to current message on gmane is pushed to killring and clipboard.

Documentation from the orgmode.org/worg/ website (either in its HTML format or in its Org format) is licensed under the GNU Free Documentation License version 1.3 or later. The code examples and css stylesheets are licensed under the GNU General Public License v3 or later.