Productivity, a year on. —
It’s been a
href="http://blog.printf.net/articles/2006/03/21/productivity">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.
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." (interactive) (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.
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 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.
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.
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.