Irreal

By now you all probably know that Emacs 24.3 is out. This is a substantial release with lots of new goodies. I could write a long blog post about them but fortunately Mickey has has already done the work so I can be lazy.

As usual there was no problem compiling and installing Emacs. For OS X it’s just

./configure --with-ns
make install
cp -R nextstep/Emacs.app /Applications

If you’re on a different platform, just follow the directions in the INSTALL file.

This time I did have configuration problems. The first thing that happened was that Emacs couldn’t activate org2blog during initialization because it couldn’t find org. Of course, org was there but it wasn’t being managed by ELPA so I set it to be loaded by ELPA. That didn’t bother me because I’d been meaning to move the rest of my packages over to ELPA anyway. After that, everything loaded without problem. I started happily writing this post but when I went to insert the above link to Mickey, I got an error complaining that org-no-popups was not a valid function. After a little investigation I discovered that the Org folks are recommending against loading org with ELPA because of this error—they claim it’s a problem with ELPA. Now I was back to org2blog not loading. I moved that out of ELPA too and everything starting working fine.

I’d rather have everything in ELPA but I can live with the current situation. At least everything is working again. The takeaway is that if you’re an Org user (and are loading the latest version rather than the builtin) you may want to move it out of ELPA.

Once I got past the initialization problems, everything ran fine. As I said, this is a substantial release so it’s worth getting it installed as soon as you can find the time.

Regular reader Phil offers some help on help in the comments to the vc-annotate post. The first suggestion is something I think he’s mentioned before but that I promptly forgot. I often want to look at the source code that implements an Emacs command. Sometimes it’s just curiosity, other times I want to extend or modify the command or implement something similar. My normal procedure for this is to bring up the help page for the command with 【Ctrl+h f】 and then click on the link to the source code. Actually, there’s a function that does that for you: find-function. Phil assigns the key sequence 【Ctrl+h Ctrl+f】 for this. I do this operation often enough that this is a real time saver for me and I’ve added it to my init.el.

The second two commands are built in but virtually unknown. The sequence 【Ctrl+h F】 is just like 【Ctrl+h f】 except that it brings up the info page for the command. Similarly 【Ctrl+h K】 brings up the info page given the key sequence for the command.

These are really useful things to know so we all owe Phil thanks for (once again) pointing them out. Maybe now that I’ve blogged about them I’ll actually remember them.

Yesterday, I wrote about the video chat between Sacha Chua and Avdi Grimm. The take away from that post was vc-annotate, a powerful Emacs tool that hooks into your version control’s annotation facility. Right at the end of the chat—about 42:25—Grimm makes another important point that we’ve discussed here at Irreal many times.

He says that the real power of Emacs is that it’s not just an editor but a Lisp Machine. What makes that important is that we can write our own development environment and take it with us wherever we go: it’s portable. Portable across projects, machines, and operating systems. That’s because it all lives in the Emacs Lisp Machine. Most of us, of course, don’t sit down and write a complete development environment before we start actually developing. Rather, we add small tools, shortcuts, and hacks to the stock Emacs distribution as we encounters pain points.

After a few years of that, we end up with a highly customized environment specifically suited to our work flow. This becomes so important that it would be painful to have to abandon it upon moving to another project or platform. The nice thing with Emacs is that we don’t have to. It’s all part of Emacs and our individual .emacs or init.el files.

The logical consequence of this is that many of us reach a state where we hate to leave Emacs and move as much of our environment as possible into it. You know you’ve reached that point when you find that you’re trying to convince yourself that, really, W3M is almost as good as Safari/Chrome/FireFox or whatever. We mostly don’t believe that but it makes us grumpy that we can’t run a browser inside Emacs the way we do a shell.

The Internet’s tireless blogger Sacha Chua has another interesting video chat about Emacs. This time it’s with Avdi Grimm, a well-known Ruby guru and Emacs user. The video is informative and definitely worth 40 minutes of your time so give it a look when you get a chance.

Towards the end, Grimm talks a little about how many developers use all sorts of suboptimal strategies for learning about the history of a piece of code. Many switch to a terminal and interrogate their version control system. Some go to github and browse the history there. Some even comment out old code so that the history is always there in the file. As Grimm points out, none of that is necessary if you’re using Emacs or other decent programmer’s editor. In the case of Emacs, you need merely invoke vc-annotate and a color coded history of the file is displayed along with the commit id, committer, date, and other information. From there you can drill down and get further details. Grimm has an excellent short video¹ that demonstrates some of its functionality.

The nice thing is that vc-annotate is in stock Emacs so you don’t need to do anything to use it. Just bring up a file that’s under version control and type【Meta+x】 vc-annotate or 【Ctrl+x v g】 to try it out. You can read about vc-annotate in the Emacs manual or under the Old Revisions node in Info. This is a great feature; I can’t believe I didn’t know about it.

Emacs 24.3 Release Candidate 1 is available for FTP download. If all goes well, the developers expect to release 24.3 in about a week. Consider jumping in to help with the final testing if you can.

After all the heavy breathing about Emacs UI issues recently, here’s a softer, gentler Irreal take on Emacs bling. If, like almost everybody, you’re invoking Emacs from some sort of GUI you’ve undoubtedly seen the Emacs logo. I’ve pretty much never given it a second thought but that was wrong.

The Emacs logo, and others like it, don’t just happen. Someone has do design and draw it. Here’s a very nice history of the current logo and how it was developed. What strikes me is how, at the same time, it was both instantaneous and drawn out. On the one hand, Luis Fernandes could draw trial logos in just a few seconds but it took a very long time to settle on a final design and get everyone to sign off on it.

The above link is a very nice history of the design of our current logo and should give you an appreciation for a part of Emacs development that most of us never think about. Well worth a few minutes of your time.

I just saw a reference to Pallet on reddit. It’s a way of syncing your Emacs packages across several machines. For example, you might, like me, have several machines and want your ELPA configuration to look the same on all of them. The usual strategy of throwing everything in git or some other version control can cause merge conflicts and other problems. Pallet is supposed to handle the syncing in a more efficient way.

It looks pretty nice but judging from the comments it’s very new and no one commenting on reddit had any experience with it. Does anyone here have wisdom to share about it?