Irreal

Charles Choi is back with another app in his Casual Suite. This time it’s for dealing with images from within Emacs. As Choi says, there are better ways of dealing with images than from within Emacs but for those of us addicted to the Emacs flow, the less than optimal UX may be worth it. Thus: Casual Image.

The idea, as with all the Casual apps, is to provide an easy to use transient menu for dealing with hard to remember, esoteric commands. In this case it’s for the built-in image-mode.

Again, Emacs may not be the best way to deal with this problem but it does allow us to stay within Emacs and leverage the power of our favorite editor. Choi says that this Casual app is more opinionated than usual because image-mode’s commands are particularly poorly named so Casual Image renames them. Take a look at the menu on Choi’s announcement, linked above, to see what he means.

The only downside to Casual Image that I can see is that it requires ImageMagick to be installed. That’s not much of a downside given that you’re dealing with images. If you deal with images all the time, there are probably better ways of dealing with them but if it’s an occasional thing and you like staying in Emacs, Casual Image may be just what you need.

Protesilaos Stavrou (Prot) has another really excellent video up. This time it’s about organizing your Emacs configuration file. Prot looks at two possible approaches. The first is to use the built-in outline mode and appropriately marked comments to have an Org-mode-like presentation of your init.el with section folding and easy search.

The second approach is probably the most common today. It’s to write your configuration file as a literate Org document and tangle the code into the file that Emacs loads at startup. There’s a lot to be said for this approach. You can completely annotate your configuration with what it’s doing and why it’s doing it in that particular way. That’s especially useful if you want to share your configuration. You can export it to HTML, PDF, or even something like Docx. It is, after all, just another Org document.

All of that is old news, of course, but the real benefit for me from Prot’s video is how you can start with a traditional init.el and transform it into a literate Org document. The nice thing is that this can be done piecemeal so that you can convert it bit by bit over a period of time.

It’s pretty easy. First just put the whole init.el into a single code block in the new Org file. You can add a title and perhaps some introductory comments. Finally add a property that tells Org where to tangle the file and you can generate your init.el directly from the new Org file.

The key to breaking the Org document into sections is the org-babel-demarcate-block command. This command splits the current block into two distinct blocks so that you can add headers and commentary between them. Take a look at Prot’s video to see the process in action.

If you’ve ever thought that you’d like to have a literate Emacs configuration file, Prot’s video is what you need. He shows you how to start with what you have and incrementally change it into a complete literate document.

Way back in 2005, Steve Yegge wrote a wonderful post, the-emacs-problem, that discussed why Lisp is the right language for dealing with text and why Emacs is the right tool for dealing with it. A few years later I wrote a post discussing Yegge’s post.

Recently, someone reposted Yegge’s original post and since it was so long ago, I thought it was worth revisiting. Although Yegge makes several great points, the key insight for me, is that a log file structured as S-expressions can be thought of as a program. Sure, the symbols in the function slots may not actually be functions but they can be.

I explored this a bit in in a post that looked at how to make the log file executable. It turns out to be incredibly easy and amounts to little more than defining a function for each of the tags in the function slots. The next two posts push this idea further and show how it can be easy to use the same idea to filter log entries according to some criteria. The thing to remember is that the log file started life as simple data and it was merely a change of view that allowed us to think of it as a program.

This set of posts are among my favorite Irreal offerings and, I think, make the oft quoted Lisp adage that “data is code” (and vice versa) come alive. If you really want to internalize the equivalence between Lisp code and data, read Yegge’s post and follow up with my posts. They’re over 13 years old now but, I think, have stood up well.