Productivity, a year on.

It’s been a year and a half since I wrote a blog post about
productivity tools — I mentioned some of the shell and editor tools I use, and it was fun and people gave me useful comments. Here’s another post, with some new lessons learned.


python-mode flymake

Flymake is mostly the reason I’m writing this blog post. It does incremental compiling/code checking for emacs — when you make a source code change, it passes your input to an external program, and then shows (by highlighting lines in different colours) where the external program thinks that warnings or errors are.

I use it with Python, and pylint: after a code change, pylint is run on the buffer, and emacs parses the output and shows a display like the following:

This seems like a basic thing to do, but it’s making me enjoy programming more than I ever have. My Python code almost always runs correctly first time now, as I wait for the pylint warnings to go away before trying it, and I get cheered up (and, frankly, shocked!) every time I write another fifty lines of code and it works straight away. I totally recommend it. The setup’s documented on emacswiki.


I often work on the kernel or Xorg, and I would be totally ridiculously lost with both if I wasn’t using “tags” support in my editor. Here’s how it works: you run etags over your .[ch] files (or make tags in
a kernel source dir), and it generates a TAGS index. You load that in emacs with M-x visit-tags-table, and with the below keybinding, pressing F10 will take you to the original definition of whichever symbol the cursor is on, no matter where it appears in the source tree.
Within a few presses of F10, you’ve escaped macro hell and found where the code that actually defines the function you’re interested in is.

(defun find-tag-at-point ()
  "*Find tag whose name contains TAGNAME.
  Identical to `find-tag' but does not prompt for
  tag when called interactively;  instead, uses
  tag around or before point."
      (find-tag (if current-prefix-arg
                    (find-tag-tag "Find tag: "))
                (find-tag (find-tag-default))))

(global-set-key [f10] 'find-tag-at-point)


Also, there’s fairly good GIT support in emacs, which mostly consists of turning each GIT shell script into an emacs command you can run with M-x. I use this, but it’s not particularly exciting.

M-x gdb

emacs22 has a new graphical GDB mode. It is awesome. Here’s a screenshot from Phil Sung.


I’m trying to get the hang of emacs org-mode, but I’m not quite there yet. I mostly want something to manage my TODOs that don’t have hard deadlines and my diary/appointment entries that do. If anyone feels like bragging about their great org-mode setup and sharing code, go right ahead.


All of the hosted projects at OLPC use GIT, for better or worse. I thought it was for worse for a while, especially when GIT 1.4 came out and made me hate branches all over again, but there are a few new features that are making me like GIT more:

git rebase –interactive

Pierre Habouzit has already written plenty about this. Solves the “wait how do I revert this one commit I made twenty commits ago” problem, and some other ones too.

git stash

git stash lets you temporarily store changes away while you get your tree in a different state; examples are in the man page.

git add –interactive

“Anonymous” commented on this post:

Don’t forget `git add –interactive` (in newer git). It allows you to commit only certain hunks of a patch.



While working on a kernel driver, I was wishing for a way to take a hex number (that represented a bitfield) and print its binary decoding without having to do so in my head. The command /usr/bin/i (available as iprint in Debian/Ubuntu) does this. For example:

pullcord:cjb~ % i 0x4F
79 0x4F 0117 0b1001111 'O'

(The order there is: decimal, hex, octal, bitstring, ASCII.)

Even though this solves my problem well, I’d still like the kernel printk() to get a formatting string for “binary string” itself. I wonder if a patch would be accepted.

rpmbuild –short-circuit

I’m used to Debian’s make-kpkg, which lets you hack on a kernel source tree and then build a package out of it. rpmbuild instead wants you to supply a tarball and patches for a source tree for it to unpack, patch and build with all at once. You can get around that with the --short-circuit option, which skips steps before the one you’re after. So, rpmbuild --short-circuit -bc goes through the build and install phases, skipping the prep stage.

zsh share_history

setopt share_history lets each of my shells use the same history file, and the file is updated after every command is run, so I no longer have to flick through each shell window wondering which one in particular contains the shell with a copy of the long command I ran
in its history.


  1. Hi,
    I believe org-mode can already do what you want without any special configuration. You may want to give a look at these tutorials (if you didn’t already)

    and this screencast:

    Also at

    there’s a .emacs file that contains a quite complicated configuration for org-mode.


  2. bash: shopt -s histappend
    ..will synch your history.

    What’s nice (as you’re using emacs already) is to use M-x shell. Now you can use emacs history rather then the shells.

    For example, C-r does in incremental search backwards through your shell output.

    Or C-c TAB (icicle-comint-command) lets you run a previous command by typing bits of it and having the candidates complete automagically in the mini-buffer. This beats shell history!

    (Oh yeah, you need icicles, which rocks)

    (savehist-mode 1)

    Sometimes, you don’t want to clutter up your shell buffer with the output from some utility command. Don’t get lost in multiple terminals or buffers: M-!.

  3. What’s nice (as you’re using emacs already) is to use M-x shell. Now you can use emacs history rather then the shells.

    M-x shell appears not to know how to interpret ANSI for me, which is a dealbreaker. I tried M-x ansi-term once, but it doesn’t have the same C-r, and I kept getting tied up in the way it overloads control/meta/etc.

    Thanks, though. 🙂

  4. When I activate flymake-mode with python using this technique, it seems to deactivate my syntax highlighting when it parses the buffer.. have you noticed that at all? I’d rather have both if possible =P

  5. seems to deactivate my syntax highlighting when it parses the buffer

    Wow, never seen that. I wonder if it still happens when you do –no-site-file.

  6. I am on my first steps with git and had some trouble with branches. Searching for some hints I come accross your site. Bad to read “hate branches all over again”. However, git seems to be very straightforward and fast. And good to know that there is great emacs support for git.



Leave a Reply to Anonymous Cancel reply

Your email address will not be published. Required fields are marked *