nice-looking pdfs with org-mode and xetex

I've discussed the wonderful org-mode here a number of times already. It has become a pretty important part of my overall workflow. One thing I am using org-mode for, is to produce all kinds of PDF-documents that I can share with other people.

org-mode & LaTeX

In the past, I often used straight LaTeX for such things; I wrote my thesis with it, but also many other documents. There are many things I like about LaTeX, one of them being that I can use emacs for writing. Still, there are also a few things I do not particularly like. First, I think LaTeX is quite heavy with formatting directives, which hinder my writing flow (e.g., when I want to include an image, a table or a source code snippet). Another thing is that I find the default LaTeX styles a bit boring. Nothing wrong with it, but there just too many documents with the exact same lay-out.

Now, back to org-mode. One way to use org-mode is as a friendly way to generate LaTeX (and, consequently, PDFs). This is a big improvement! Much more than LaTeX itself, org-mode allows to focus on the contents of the document, rather than instructing LaTeX what to do. This comes at the price of small bit of flexibility, but, if needed org-mode allows you include straight LaTeX when needed – so while keeping easy things easy, hard things are still possible. The latter does require a bit of experience with LaTeX a though.

setting up XeTeX

Now, for the second issue, the way documents look, there are other solutions, and they live on the LaTeX side of things. I'm sure many have seen The Beauty of LaTeX. Using the XeTeX implementation of LaTeX and the fontspec package, you can create LaTeX documents with a bit 'refreshed' look.

So, the steps to get this working with org-mode:

• install the texlive-xetex packages on Ubuntu and Debian (this installs a huge set of packages)
• install the SIL fonts (I'm using ttf-sil-gentium and ttf-sil-charis, but there are more)
• I'm also using DejaVu Mono (ttf-dejavu)

teaching org-mode about the new XeTeX stuff

We now need to define some LaTeX document class for org-mode that uses XeTeX and some of these new fonts. Let's call the document class djcb-org-article (as I often use the djcb- prefix for my own stuff), it could be something like the following (add to your org-setup – e.g., in your .emacs, make sure there is a (require 'org) before this:

;; 'djcb-org-article' for export org documents to the LaTex 'article', using
;; XeTeX and some fancy fonts; requires XeTeX (see org-latex-to-pdf-process)
(add-to-list 'org-export-latex-classes
  '("djcb-org-article"
"\\documentclass[11pt,a4paper]{article}
\\usepackage[T1]{fontenc}
\\usepackage{fontspec}
\\usepackage{graphicx} 
\\defaultfontfeatures{Mapping=tex-text}
\\setromanfont{Gentium}
\\setromanfont [BoldFont={Gentium Basic Bold},
                ItalicFont={Gentium Basic Italic}]{Gentium Basic}
\\setsansfont{Charis SIL}
\\setmonofont[Scale=0.8]{DejaVu Sans Mono}
\\usepackage{geometry}
\\geometry{a4paper, textwidth=6.5in, textheight=10in,
            marginparsep=7pt, marginparwidth=.6in}
\\pagestyle{empty}
\\title{}
      [NO-DEFAULT-PACKAGES]
      [NO-PACKAGES]"
     ("\\section{%s}" . "\\section*{%s}")
     ("\\subsection{%s}" . "\\subsection*{%s}")
     ("\\subsubsection{%s}" . "\\subsubsection*{%s}")
     ("\\paragraph{%s}" . "\\paragraph*{%s}")
     ("\\subparagraph{%s}" . "\\subparagraph*{%s}")))

Of course, this can be customized to your own preference; e.g., North-Americans may not be using A4-paper.

org-mode takes care of the export from its own format to LaTeX, but we need to tell it to use xelatex to process the LaTeX to PDF:

(setq org-latex-to-pdf-process 
  '("xelatex -interaction nonstopmode %f"
     "xelatex -interaction nonstopmode %f")) ;; for multiple passes

That's all that's needed on the setup-side.

creating a document

Now, let's create a little test document, test.org, to show how it works:

#+LaTeX_CLASS: djcb-org-article
#+TITLE: My little document

* Introduction
  
  This is my document. There are many like it, but this is mine. It's easy to
  write without *too* _many_ /distractions/.
  
** Normal distribution

   Probability density of the normal distribution, using familiar TeX notation
   for formulae:
 
   $$\frac{1}{\sqrt{2\pi\sigma^2}}e^{ -\frac{(x-\mu)^2}{2\sigma^2} }$$

** Some table

| *Greek God* | *Roman God* | *Element*      |
|-------------+-------------+----------------|
| Zeus        | Jupiter     | Sky and clouds |
| Hera        | Juno        | Family         |
| Poseidon    | Neptune     | Sea            |
| Hades       | Pluto       | Underworld     |

We can export this to a PDF using C-c C-e p (or C-c C-e d to automatically open the PDF in a PDF-viewer). This should all work nicely; if it doesn't, note that when exporting, say, test.org, org-mode will create a file called test.tex, and visit in a buffer. There's also a buffer with the output from various commands, but sometimes it can be useful to run LaTeX (xelatex in this case) on the file by hand, to find any problems. The wonderful org-documentation about exporting to LaTeX has more information.

I think the result is pretty nice – it stays true to the class LaTeX article class, but freshens it up a bit with some news font. If you can make something better – which is not unlikely – you are of course invited to contribute your own!

Concluding

org-mode is a pretty convenient way to write nice-looking PDFs. Combined with xelatex, they don't have to look too plain :). However, I'm aware of my limitations when it comes to the coolness/aesthetic aspects, but I hope others can show the way here.

Maybe org-mode could ship with a number of ready-made templates to make it easy to make nice-looking documents, resumes, reference cards, reports, meeting notes and so on.

searching e-mails with wanderlust and mu

I have discussed the Wanderlust e-mail client a couple of times already. I'm still using it, so I keep on learning new tricks. Even though there has been quite a bit of action in the competing gnus e-mail client, for my particular use-case, Wanderlust is still the best option.

'My particular use-case' consists of storing my mail in Maildirs, which I fill with either offlineimap (which has fortunately found a new maintainer) or fetchmail.

mu

When dealing with e-mail, one particularly important feature for me is the ability to search my messages. In fact, it's so important for me that I wrote some software to do this for me; the software is called mu; it indexes the messages in my Maildirs, and then allows for searching them using queries, based on message contents, headers, or other message properties.

mu works through a command-line interface, although there is an experimental GUI available as well. The command-line interface makes it possible to hook mu up with various mail-clients, such as mutt, or Wanderlust. Some Linux distributions ship mu, but since the versions they ship are often a bit outdated, I recommend building it yourself from the sources linked on the mu website. The process is fairly straightforward; and there is plenty of documentation in the form of man pages.

mu and wanderlust

I've been combining mu and wanderlust for a while (see mu and wanderlust - the old way, below), but this week Sam B. on the mu mailing list showed a way to do so in a much more elegant way - using virtual or query folders.

How does this work? Well, after installing mu, add the following to your Wanderlust setup file (~/.wl or it's moral equivalent – see the older Wanderlust posts for the details):

(require 'elmo-search)
(elmo-search-register-engine
    'mu 'local-file
    :prog "/usr/local/bin/mu" ;; or wherever you've installed it
    :args '("find" pattern "--fields" "l") :charset 'utf-8)

(setq elmo-search-default-engine 'mu)
;; for when you type "g" in folder or summary.
(setq wl-default-spec "[")

So, to start with the last part, whenever you type g in folder or summary, in the mode-line you will get something like Folder name (.inbox): [. Now simply type your mu search expression and press Enter, and wanderlust opens a (temporary) folder with the search results. Brilliant!

Next, to add virtual folders for searches you do often, simply add some folder specifications like the following to your .folders file (again, check the older Wanderlust posts if you're not familiar with folders-file):

VFolders {
# message I received today
  [date:today..now]!mu  "Today"

# messages bigger than 1Mb  
  [size:1m..100m]!mu    "Big"

# signed messages i got in 2010 related to emacs
  [date:2010..2011 flag:signed emacs]!mu "Signed-Emacs2010"

# unread messages
  [not flag:seen]!mu    "Unread"
# or (for mu  >= 0.9.4):
# [flag:unread]! mu      "Unread"
}

After this, restart Wanderlust, and there you go! Wanderlust will display your brand new virtual folders with an icon that looks like a little whale.

You can put arbitrary mu search expressions between the [], matching whatever is useful in a certain case. Check the mu documentation to see how to do this.

Note, the messages you get in these virtual folders are links to the original messages. In practice, this means that changes you make to the links do no affect the originals – if you delete a link you're not deleting the message.

mu and wanderlust - the old way

This discussion would not complete without a description of the old way I used search. This method may still be useful for integrating mu with other clients such as mutt.

What I've been using for a while is a (in retrospect) rather clumsy way to integrate message searches with Wanderlust: based on the results of a query, I would create some special Maildir and fill it with symbolic links to the matched messages, and the visit this special Maildir with Wanderlust. I'll include the code here to contrast it with the more elegant solution that we saw before, but also because the approach taken might be easily adapted for other mail-clients.

;; search using mutt
(defvar mu-wl-mu-program     "/usr/local/bin/mu")
(defvar mu-wl-search-folder  "search")

(defun mu-wl-search ()
  "search for messages with `mu', and jump to the results"
   (let* ((muexpr (read-string "Find messages matching: "))
          (sfldr  (concat elmo-maildir-folder-path "/"
                    mu-wl-search-folder))
          (cmdline (concat mu-wl-mu-program " find "
                      "--clearlinks --format=links --linksdir='" sfldr "' "
                     muexpr))    
          (rv (shell-command cmdline)))
    (cond
      ((= rv 0)  (message "Query succeeded"))
      ((= rv 2)  (message "No matches found"))
      (t (message "Error running query")))
  (= rv 0)))

(defun mu-wl-search-and-goto ()
  "search and jump to the folder with the results"
  (interactive)
  (when (mu-wl-search)
    (wl-summary-goto-folder-subr
      (concat "." mu-wl-search-folder)
      'force-update nil nil t)
    (wl-summary-sort-by-date)))

;; search by pressing 'Q'
(define-key wl-summary-mode-map (kbd "Q") ;; => query
  '(lambda()(interactive)(mu-wl-search-and-goto))) 
(define-key wl-folder-mode-map (kbd "Q") ;; => query
  '(lambda()(interactive)(mu-wl-search-and-goto))) 

After installing mu and putting the above in your wanderlust startup file, you should be able to search by pressing Q. The mu documentation has an example for mutt as well.

conclusion

It's straightforward to integrate advanced searching capabilities to Wanderlust using mu, and thanks to Sam B., it's gotten a lot easier! The second (old) approach may be useful as 'inspiration' for use in other e-mail clients as well, if they do not provide the kind of hooks that the first solution needs.

IELM: a REPL for emacs

Emacs-lisp (elisp) is a nice language to play around with code and try things as you develop them – explorative programming. I often use the *scratch* buffer for that, but sometimes it's nice to use a so-called 'REPL' ( Read-Eval-Print-Loop) instead. A REPL is a sort-of command-line interface where your expressions are evaluated as soon as they are considered 'complete' and you press Enter.

So, enter Emacs's built-in repl: IELM. You can activate it with M-x ielm, and the interaction looks something like the following:

*** Welcome to IELM ***  Type (describe-mode) for help.
ELISP> 123 
123
ELISP> (+ 1 2)
3
ELISP> ;; comment
ELISP> (defun fac (n)
         (if (= 0 n)
           1
           (* n (fac (- n 1)))))
fac
ELISP> (fac 5)
120
ELISP> 

By default, IELM evaluates complete expressions automatically as soon you as you press Enter. So one thing to remember is that if you want to have multi-line expression (like above), you must make sure that after each line the expression is not complete (i.e., the brackets are not balanced) -- otherwise the expression will be evaluated too early. That makes modes like autopair or paredit a bit inconvenient for this.

If you don't like that behavior, you can do:

(setq ielm-dynamic-return nil)

which will allow you to Enter as much as you want and only evaluate things when you press C-j. But then you might as well use *scratch* I suppose. Personally, I use IELM mostly as a calculator.

executable source code blocks with org-babel

org-babel is the mechanism that org-mode offers for evaluating (executing) blocks of source code embedded in your org-mode-documents. This is useful for so-called reproducible research, i.e., where you allow your readers to go through the steps that led to your results.

Here, I'm just scratching the surface with some simple examples.

source code blocks

Let's first look at how it all began: source code blocks. I guess most org-mode-users will be familiar with those: the ability to include syntax-highlighted ('font-locked') snippets of source code in org-documents. We discussed source blocks before, they look like this:

#+begin_src perl
sub my_func {
        print "Hello, world!\n";
}
#+end_src

And note that code blocks can be edited in their 'native mode' using C-c'= (or, =org-edit-src-code).

When code block like this are exported to, say, HTML, they'll look like the following fully highlighted snippet (assuming you're reading Emacs-fu in it's full-color version):

sub my_func {
        print "Hello, world!\n";
}

evaluating source code

org-babel takes this a few steps further: instead of just looking at source code, we can actually evaluate (execute) it, using the org-mode-based system called org-babel.

If you have a recent version of org-mode (7.x or later), add the following to your .emacs (or equivalent):

(org-babel-do-load-languages
 'org-babel-load-languages
  '( (perl . t)         
     (ruby . t)
     (sh . t)
     (python . t)
     (emacs-lisp . t)   
   ))

This enables org-babel for the mentioned languages; there are many other languages available as well.

Now, suppose we have a snippet of python in an org-mode-buffer:

#+begin_src python
def hello(str):
        return "Hello, " + str + "!"
return hello ("dude")
#+end_src

You can move the cursor (point) inside the src-block and press C-c C-c (or, org-confirm-babel-evaluate). This causes the block of code to be evaluated (executed), after asking you for confirmation. The result will inserted below the block, like:

#+results:
: Hello, dude!

Note, in the hello example, the result of the block is the value of the evaluation - that is, the value of the last expression evaluated. This is the also the default, so we don't need to (but could) write:

#+begin_src python :results value

The alternative is to use the (standard) output of the function, which is activated with :results output, e.g.:

#+begin_src sh :results output
   echo "Hello $USER! Today is `date`"
#+end_src

Moving to this block and pressing C-c C=c would get you something like the following – probably with a different username and time:

˜#+results:
: Hello djcb! Today is Sun Feb 27 13:51:50 EET 2011

almost like functions

org-babel also allows you to refer to the code blocks from elsewhere in your document, by labeling your code-blocks with srcname. Let's say we have some Ruby code to revert a string:

#+begin_src ruby
def revert(s)
  if s == "" then 
    return ""
  else
    return s[-1].chr + revert(s.slice(0, s.length()-1))
  end
end
revert(str)
#+end_src

We can now 'call' this block; note that we get the result of evaluating the block. So if you want to use the result of a function in the block, you also need to add the call to that function (see the last line).

Now, we can use:

#+call: revert(str="VeryCoolStuff")

And we get:

: ffutSlooCyreV

Note, due to some limitation/bug in my version of org-babel, the strings should not contain spaces or other special characters, so the following will give result in an error note:

˜#+call: revert(str="Very Cool Stuff")

Whenever you try to evaluate a code block, emacs will ask for confirmation -- this is important, because of the obvious security implications of executing unknown code. Anyway, if you do trust the code, you can use the following to skip the confirmation:

(setq org-confirm-babel-evaluate nil)

These simple examples do not really capture the power that org-babel brings, but it's a start. There is quite a bit of documentation for org-babel to help you further. Finally, if you are already using org-babel, feel free to share your experiences in the comments!

keeping your secrets secret

If you want to keep your secrets secret, it is a good idea to encrypt your data; I usually do that for files with passwords for various services, banking data, and so on. Since version 23, Emacs includes a package called EasyPG (an interface to GnuPG) which makes this seamless – just make sure that you have GnuPG installed.

It's easy to use EasyPG – the only thing you need to do is adding the .gpg -extension to your files, and EasyPG will automatically encrypt/decrypt them when writing/reading. So, for example, to create an encrypted org-mode-file, simply visit (C-x C-f) a file with a name like myfile.org.gpg; emacs opens this in Org-Mode (just like any .org-file). When you want to save the file, emacs will ask you for a password, and with this same password, you can open it again. Don't forget that password!

account data

You can store any kind of secret data in your encrypted files. One type I find particularly useful is to store account data (user names, passwords) for various services there. For example, I use the emacs identi.ca-mode client, which gets its account data through variables identica-username and identica-password.

I do not want to put this information in my main .emacs file for safety reasons, but instead, put it an encrypted file, together with the account data for other services (mail, twitter etc.). Emacs' require does not understand encrypted files, but load-library does. To deal with that, I have two files, secrets.el and secrets.el.gpg (in my load-path):

;; secrets.el
(load-library "secrets.el.gpg")
(provide 'secrets)

and

;; secrets.el.gpg
(setq identica-username "djcb"
      identica-password "$ekr3t")
;; ... other passwords ...

Now, in my .emacs I have a function for various services, like:

(defun start-identica ()
  (interactive)
  (require 'secrets)
  (identica-friends-timeline))

This will prompt me for the password, but only if I use anything that requires the secret data, and only once per session.

Update: as Richard notes in the comments, you can also use require by explicitly specifying the filename (parameter two). That might actually be easier -- thanks Richard!

using public keys

By default, EasyPG performs symmetric encryption; if you want to use public key encryption instead (useful when you want to share the encrypted files with others), you can use:

;; 'silent to use symmetric encryption
;; nil to ask for users unless specified
;; t to always ask for a user
(setq epa-file-select-keys t) 

The 'users' in this snippet are the people in your GnuPG-keyring – EasyPG lists your keyring inhabitants, allowing for easy selection. You can also specify the people who can decrypt your file by putting something like the following at the beginning of the file you want to encrypt.

# -*- epa-file-encrypt-to: ("foo@bar.org") -*-

so

EasyPG brings more functionality for encryption, decryption, signing, managing your keyring and so on, but I haven't used that much yet. Anyhow, the automatic support for reading/writing file is really nice.

extending ERC with your own commands

ERC is the leading Emacs-based IRC-client; I already discussed ERC before. I have been using ERC a lot in recent times, as it's an essential way to communicate at work with team members in remote locations. There are other IRC-clients – most people around me seem to use either irssi or xchat, but these don't integrate so well with my emacs-based workflow, the easy with which it can be extended to do exactly what I want; in this although they have their own strenghts. One of the great strengths of ERC is article I give some examples.

Apart from chatting, you can send commands (long list) to the IRC-server, for example to request information about other users, change your 'nick', leave the channel, and so on. As in most IRC-clients, you can send these commands with ERC by prefixing them with /, so you'd type:

/nick ninjaturtle

to change your nickname.

The nice thing about ERC is how easy it to add your own commands to this. In your .emacs (after loading ERC), you can add something like:

(defun erc-cmd-MYSYSTEM ()
  "show some information about my system"
  (let ((str (shell-command-to-string "uname -a")))
    (when str (erc-send-message str))))

Or, add add a function called erc-cmd-XXXX (with the XXXX being the command name in capitals, will add command XXXX, which you can invoke with /XXXX or /xxxx). So, with the above function, I can now do something like:

ERC> /mysystem
<djcb> Linux cthulhu 2.6.35-25-generic #44 SMP Fri Jan 21 17:40:48 UTC
       2011 i686 GNU/Linux

Let's look at some other (somewhat) useful command: /calc; again, just a small example, I'm sure something can come up with something a bit more elegant - perhaps using emacs' built-in calc.

(defun erc-cmd-CALC (&rest args)
  "calculate value of some expression using bc"
  (let ((expr (mapconcat 'identity args " ")))
    (when (length expr)
      (let ((result (shell-command-to-string (concat "echo '" expr "' | bc "))))
        (when result (erc-send-message (concat expr " = " result)))))))

ERC> /calc 2 * (3 + 4) / 7
<djcb> 2 * (3 + 4) / 7  = 2

Now, a small warning, just because it's easy to dump the output of, say, cowsay in an IRC-channel using your own /cowsay command, does not mean it is a good idea – in fact, using something like that is guaranteed to get you kicked out fairly quickly from many channels.

That being said, I'm sure many people have come up with much more clever things than the examples here; feel free to share your inventions in the comments!

setting the frame title

The 'frame title' (window title) that emacs uses in graphical environments defaults to something like emacs@hostname.

Of course emacs lets us customize this, by changing the value of frame-title-format. Emacs accepts many different things there, (see the documentation for frame-title-format and mode-line-format for that), but let's look at an example.

Instead of the default emacs@hostname, I find it more useful to include the name of the file I'm working on instead, or, in case of non-file buffers, the buffer name. To do this, I have something like the following in my .emacs:

(setq frame-title-format
  '("" invocation-name ": "(:eval (if (buffer-file-name)
                (abbreviate-file-name (buffer-file-name))
                  "%b"))))

As you see, frame-title-format is a template for the items that are present in the title bar; i.e.. emacs concatenates the items in the list, and it supports various %-constructs, which are replaced with actual values; see below.

In addition to the %-constructs, you can use :eval to make emacs evaluate the expression whenever it wants to update the title bar.

invocation-name is the name of the emacs binary.

abbreviate-file-name replaces the home directory part in file names with ~; for very deep paths it might be nice to do some abbreviation as well as some shells do; this is left as an exercise to the reader :)

You can experiment with some other things to put in frame-title-format; use the :eval construct as above to use emacs-lisp functions, and the various %-specifiers which are replaced by certain values; the emacs documentation lists the following:

%b -- print buffer name.      %f -- print visited file name.
%F -- print frame name.
%* -- print %, * or hyphen.   %+ -- print *, % or hyphen.
      %& is like %*, but ignore read-only-ness.
      % means buffer is read-only and * means it is modified.
      For a modified read-only buffer, %* gives % and %+ gives *.
%s -- print process status.
%i -- print the size of the buffer.
%I -- like %i, but use k, M, G, etc., to abbreviate.
%p -- print percent of buffer above top of window, or Top, Bot or All.
%P -- print percent of buffer above bottom of window, perhaps plus Top,
      or print Bottom or All.
%n -- print Narrow if appropriate.
%t -- visited file is text or binary (if OS supports this distinction).
%z -- print mnemonics of keyboard, terminal, and buffer coding systems.
%Z -- like %z, but including the end-of-line format.
%e -- print error message about full memory.
%@ -- print @ or hyphen.  @ means that default-directory is on a
      remote machine.
%[ -- print one [ for each recursive editing level.  %] similar.
%% -- print %.   %- -- print infinitely many dashes.
Decimal digits after the % specify field width to which to pad.

So, if we'd like to include the host (system) name and some indication of the status of this buffer, we could do something like:

(setq frame-title-format
  '("emacs%@" (:eval (system-name)) ": " (:eval (if (buffer-file-name)
                (abbreviate-file-name (buffer-file-name))
                  "%b")) " [%*]"))

Of course, some of the information is available elsewhere already, but it might be clearer in the frame-title. Or not – there's a lot of room for tweaking and experimentation here.