remember Mutt's mail in Org-mode and jump back to them
As
already
anticipated, I've been implementing my own
Getting
Things Done work flow. This post documents one of its main
bricks: the integration between
Mutt and
Org-mode.
As a geek, my main incoming stream of TODO items and information
in general is email. As emails hit my INBOX, I either deal with
them immediately (reply, archive, delete) or I need to store them
elsewhere, possibly adding extra information such as a deadline, a
personal note, the associated next action, the context in which it
is actionable, etc. This need of adding extra information is what
defeats the usage of my mail client (Mutt) as a list manager (in
the GTD sense), and that's where I plugged Org-mode in. My main
goals are:
-
create Org-mode notes from Mutt, referencing
the current email, and possibly inlining some of its metadata (e.g.
subject, sender)
-
quickly retrieve referenced emails from Org-mode
notes; ideally that should happen in my usual email
environment (i.e. Mutt), so that I can process the retrieved mail
as usual (e.g. to inform the sender that I did something about
it)
In fact, both would be straightforward to achieve if I
were using some Emacs-based mail client such as Gnus, but I resist the
Emacs operating system syndrome, and therefore I
insist in using my beloved Mutt.
Let's see how the two parts of the interaction between Mutt and
Org-mode work.
(1) Mutt Org-mode
(there
...)
The interaction from Mutt to Org-mode happens via
org-protocol.
Using it external applications can feed content to Org-mode note
templates, which are then interactively edited (via
emacsclient), and
finally filed away.
The Mutt glue macro from my
~/.muttrc is as
follow:
macro index \eR " ~/bin/remember-mail\n"
The
remember-mail
script is trivial: it parses the fed mail from STDIN (using a
couple of legacy Perl modules) and then invokes org-protocol.
The relevant configuration from my
~/.emacs is
reported below; the comments explain the various parts:
;; standard org <-> remember stuff, RTFM
(org-remember-insinuate)
(setq org-default-notes-file "~/org/gtd.org")
(setq org-remember-templates ;; mail-specific note template, identified by "m"
'(("Mail" ?m "* %?\n\n Source: %u, %c\n %i" nil)))
;; ensure that emacsclient will show just the note to be edited when invoked
;; from Mutt, and that it will shut down emacsclient once finished;
;; fallback to legacy behavior when not invoked via org-protocol.
(add-hook 'org-remember-mode-hook 'delete-other-windows)
(setq my-org-protocol-flag nil)
(defadvice org-remember-finalize (after delete-frame-at-end activate)
"Delete frame at remember finalization"
(progn (if my-org-protocol-flag (delete-frame))
(setq my-org-protocol-flag nil)))
(defadvice org-remember-kill (after delete-frame-at-end activate)
"Delete frame at remember abort"
(progn (if my-org-protocol-flag (delete-frame))
(setq my-org-protocol-flag nil)))
(defadvice org-protocol-remember (before set-org-protocol-flag activate)
(setq my-org-protocol-flag t))
The result is that when you hit
ESC-R in Mutt,
emacsclient will be fired up in place presenting a note template
that already contains relevant mail information (date, subject,
from) and lets you add extra information before going away.
Additionally, the email message-id will be hidden in the note as a
mutt: hyperlink with anchor text "mail".
(2) Org-mode Mutt
(... and back
again)
Going back means that clicking on a "mail" hyperlink within an
Org-mode note should bring up a Mutt instance showing the original
message, in its context (e.g. its own mailbox). Achieving that
consists of 2 separate steps:
- looking up a specific message by
Message-ID
- firing up Mutt on the looked up message
For the first part I use
maildir-utils
(AKA
mu): a
Xapian-based mail indexing tool, which nicely integrates with Mutt;
check out
my
previous blog post on the subject for a sample setup. Using mu,
Message-ID lookups are as simple as:
zack@usha:~$ mu find -f p m:E1NbJad-0007x9-B7@ries.debian.org
/home/zack/Maildir/Debian.project/cur/1264883664_0.9472.usha,U=6320,FMD5=2284e927bb93d8a2ec434f5614dc04ba:2,S
Note: I'm relying upon maildir-utils version 0.6
or greater, for all presented scripts.
For the second part I use the
mutt-open
script which fires upon a Mutt instance on the maildir containing a
specific message, and then "hits" the appropriate keys to open the
message and shutdown
the sidebar (if
desired). It is a nicely reusable script, which I've being using
elsewhere too.
The needed glue on the emacs side is just a function to invoke
mutt-open in a brand new terminal, and its declaration
as the handler for
mutt: URLs.
(defun open-mail-in-mutt (message)
"Open a mail message in Mutt, using an external terminal.
Message can be specified either by a path pointing inside a
Maildir, or by Message-ID."
(interactive "MPath or Message-ID: ")
(shell-command
(format "gnome-terminal -e \"%s %s\""
(substitute-in-file-name "$HOME/bin/mutt-open") message)))
;; add support for "mutt:ID" links
(org-add-link-type "mutt" 'open-mail-in-mutt)
Voil !
Download
Summary of scripts and configuration snippets discussed
above:
This talk at Manchester Free Software s meeting is covering the question:
Apparently, there s some hype in the Ubuntu community about Ruby 1.9.2, so let s clarify: it would be totally irresponsible to try to ship Ruby 1.9.2 in Debian Squeeze or Ubuntu Lucid.
Ruby 1.9.2 has not been released yet:
File Under: Stuff I'm guaranteed to forget if I don't write it down
I just went a bit wild and decided to get myself some mobile broadband love
-- I'm finding that I crave a bit of light 'net when I'm out and about, and
an impending change in circumstances will mean that I'm out and about a lot
more than I am currently.
I have:
This year, at DebConf 10, I'll very probably have the pride to attend the conference
along with my 22 y.o. son, Jean-Baptiste.
JB began a 3 year cycle to graduate in electronics and industrial
computing at 
Instead of using setuid programs, the goal for the future is to use fine-grained capabilities. For example, here is 
Working on some document today, it occurred to me, once again, that OpenOffice's method for designing and applying documents styling totally sucks!
Granted, this was not the first time that I cam to this conclusion but, today, I've come to realize that OpenOffice's paradigms constantly make me waste time trying to form a mental image of how every style element is suppose to relate to the other one, yet without having the full picture available within a single, easy-to-read document. Also, there is a complete lack of consistency in how style elements work. Some want to be defined in millimeters, while others want to be defined in points, while other still in number of lines. What a mess!
In short: to become remotely usable, OpenOffice needs to approach document styling via the "HTML document with a separate CSS style sheet" paradigm. In other words, I need to be able to edit styles globally, as a group and separately from the document content itself, rather than having to click my way through a multitude of dialogs, for each and every type of text elements.
To compare this with web design, there, I can focus on the actual content, formatted around semantic text elements (headers, paragraphs, block quotes, etc.) and then decide on the presentation styling as a separate global process by attaching a CSS style sheet, in which the relation between each type of text element and how it will be displayed is crystal clear, because it's handled as a unified style editing process.
I think that this is one area in which Free Software could innovate in a positive way, by distancing itself from the Redmondesque practices of Microsoft Word, from which OpenOffice borrows too much. How about having a proper Style Editor application (similar to a CSS editor), within the OpenOffice suite, while Open Writer itself would only be allowed to load the style sheets produced by it and to apply them to semantic text text elements?
This has robbed me of several days of my life, so I want to bring Google juice this this problem.
IF you have a Pylons or TurboGears application or anything else that uses the fantastic EvalException WSGI middleware for web debugging of you web program and have the following symptom:
* on a crash the traceback page shows up, but it has no css style and no images
I envisioned to write a happy blog post how we managed to finally release Debian Edu 5.0.4+edu0... 
A new release of our
):
