Saturday, 28 February 2009

Publishing an emacs buffer

Yes, another emacs post, in row, but I found this so amazingly cool that I couldn't just keep quiet.

I told myself today: "It would be cool if I could convert what is rendered in an emacs buffer to html so I can show it to others". Of course, some people had already beaten me to it.

Making it happen

I used an emacs add-on by Hrvoje Niksic called htmlize. It does all the hard work, and it does it very well.

Still, I wanted a one key solution to publish it. So I just coded these small emacs-lisp functions:

(defun publish-buffer-to (file)
"Converts buffer to html and writes it to file"
(interactive "Ffile: ")
(require 'htmlize)
(with-current-buffer (htmlize-buffer (current-buffer))
(write-file file)
(kill-buffer (current-buffer))))
(message (concat "current buffer contents published to " file)))

(defun publish-buffer ()
"Converts buffer to html and writes it to ~/public_html/emacs.html"
(publish-buffer-to "~/public_html/emacs.html"))

(snnipets provided by htmlize! =) )

Now all that was left was to provide a simple key shortcut.

(global-set-key [f7] 'publish-buffer)

And thanks to Ruslan Spivak's code I could also add an easy way to create code snippets out of regions.

So now I can easily share my emacs buffers not only on my local server but on my blog =).

Apparently there's another module to do this that might be added to emacs soon, but for now I'm very happy with this solution.

In the future, I'd like to integrate this with tramp and add better file management support so I can seamlessly post to a remote server. I would also like to make it autoreload so it can track live changes, but we'll see.

If you liked this, you can check out my .emacs

Sunday, 22 February 2009

My .emacs

I have been delaying this post for quite a while. I've been waiting until my .emacs file is "complete". Today, I realised it is never going to be complete. So here's a few notes regarding my emacs configuration and how you can use it.


I must confess, a few weeks back my emacs configuration consisted of one HUGE file and a few emacs lisp files scattered in a directory. Also, half of the tools and modes I used were installed in a system wide manner via the OS's packaging system. ...A mess.
I decided to put some order (beauty?) to it. So now my .emacs file is 9 non-comment non-whitespace lines and the rest of the configuration is well distributed several different in appropriately named files and directories. With all tools included it is 535149 LOC.

Mobility (sort of)

I love working in emacs so much that I consider most other editing options a pain. I've even considered implementing emacs-lisp in javascript so I can turn every textarea into a fully functional emacs buffer (this is way down in my list of personal-projects-i-will-do-someday due to its complexity and my lack of free time)[1].

Being a little more realistic, I decided just to put my .emacs in a git repo that I could access everywhere and which included all the things I normally use when developing (or writting in general). This way I could have all my tools everywhere customized the way I want them.
With this approach installing new tools (like JDEE) becomes a little more complicated because they are commonly packaged to be installed in a system wide manner. Also, I cannot use my OS packaging system. But the upside of having everything in one places pays off.

So, why does it say "sort of" in the title? Well, some of the tools (the ones that need non-emacs-lisp components) are compiled for my system (A 64-bit Arch Linux box). So you might have problems with them if you just clone my emacs repo in a different system.
What can go wrong? Mostly there might be problems with JDEE and AucTex. But besides that I don't see much that could go wrong in a unix system.


There are not many new and amazing things. So here's a non-exhaustive list of stuff I use every day:
* Color themes
* git support
* Auctex
* word-to-emacs (open .doc files in emacs)
* some modes: (java, haskell, erlang, javascript, etc)
* some key-bindings:
* C-x p: go to matching paren
* f9: cross highlight (line and column)
* f11: fullscreen
* f10: remove scrollbar (combined with f11 it makes a great fullscreen experience =) )
* M-/ M-: move line up/down
* f8: make frame on display
* f5: go-to-line
* enhanced clipboard interaction
* in place annotations (I'd like to make this one better)
* automatic backups
* tramp
* everything else that I forgot

What's missing

Currently I am missing:
* Slime (I haven't used Lisp in quite a while, but I'd like to start using it again. Wait for my Clojure exploration)
* Better Python support. The default mode is very good. But I'd love to have more advanced stuff like Ropemacs.
* Bookmarks. A personal project I might add soon.
* Probably some stuff I'm forgetting


I very often get asked by firends for my .emacs file (or updates from older ones). So here's a way anyone can go and use my emacs configuration:
Go to github and get a copy of my emacs repo:

> git clone git:// ~/elisp
> ln -s ~/elisp/.emacs ~/.emacs

It doesn't go without a disclaimer: This is, and will always be, an incomplete project. Though it probably is portable, it is made for my personal use and there is no guarantee it will work in different non-linux setups.

Now, I'd love to make this even more portable and add different tools to it. So if anyone have a problem or suggestion I'd love to hear it. I would, of course, like it better if the suggestions come with a link to a fork of the project where the problems are fixed and I can just pull it ;)


So, Whats the emacs feature you like the most? Which one amazes you the most? anything you couldn't live without? What do you miss from other text editors when working in emacs?


[1] The folks at Mozilla labs have done a very nice contribution to the online editing world with Bespin. I hope they keep on the good work and turn to project into something emacs-like for the web.

Thursday, 19 February 2009


In the last post I mentioned the book Programming Pearls. In the second chapter, Jon Bentley presents a simple, but interesting problem: Given a list of words, group those that are acronyms together.

If you don't know what acronyms are, it is simply a words formed from the initial letters of others. For instance, the words "pot" and "top" are acronyms; so are the words "slow" and "owls".

When I read it, I thought "This could be done with unix tools and pipes". Actually, I didn't find a way of doing it efficiently with native unix tools. The reason being that there's no horizontal sort implementation in unix. You could write something like this:

for i in `cat dict | sed 'p' | sed 'N;s/\n/*-/g'`; do echo $i |
cut -d "*" -f 2 | sed "s/\(.\)/\1-/g" | tr "-" "\n" | sort |
tr -d "\n"; echo "$i" | cut -d "*" -f 2 ; done | sort

But it won't be very efficient and it's very ugly. I didn't spend too much time thinking of a better way to do it unix-style. If you have one, please post it on the comments =)

Instead, I wrote a small python script

#!/usr/bin/env python
import sys

if __name__ == '__main__':
f = open(sys.argv[1])
for line in f.xreadlines():
line = line.strip()
print '%s-%s' % (''.join(sorted(line)), line)

and I executed:

./ dict2 | sort

which runs in about 0.47 seconds. Then, we could add another step to pretty print the acronyms, but I wasn't interested in that.

Unfortunately, the only thing that remains 'unix' about this solution is the use of sort and one pipe. This post is not so much to show my findings but to look for a better solution. Does anyone have a suggestion?