Irreal

The other day, I saw a tweet pointing at a post from 2013 by Chris Done. It was sort of interesting so I added it to my blog queue. Since then, I’ve seen several more tweets mentioning it so perhaps everyone has seen it by now. Just in case you missed it, the post’s theme was that Emacs users are like Terry Pratchett’s Igor Clan.

Igors were characters from Pratchett’s Discworld series who were experts at surgery and routinely replaced their own body parts, making repairs and improvements. That last phrase should tell you why Done thinks Emacs users are like the Igors: they are always changing and improving their editor in the same way that the Igors are always changing and improving themselves.

His thesis is that because Emacs has an extension language in which the majority of the system is written, it’s easy for each user to move things around, modify parts, and add new things to suit themselves. He says that the Rudolf Winestock’s famous Lisp Curse—Lisp’s extraordinarily expressive power leads to programmer isolation—doesn’t apply to Emacs because, after all, your editing environment is yours alone and doesn’t have to satisfy anyone but yourself.

Done’s experience is much like mine: he came to Emacs from Common Lisp and came to see it not as an editor but as a programming environment—or as I like to say, a light weight Lisp Machine. While I don’t have any interest in routinely rearranging my body parts, I do enjoy doing it to my editor.

Adrien Brochard gave an excellent talk to the New York Emacs Meetup in which he demonstrates how to build an Emacs major mode to improve a workflow. Brochard is working with Kubernetes and would like a way to look at—or even tail and follow—the logs. For those who don’t know what Kubernetes does, or perhaps have never heard of it, it’s a system for controlling a set of processes (called pods).

Kubernetes, of course, has a way of displaying and tailing the logs but you first have to call a Kubernetes command to list all the pods, which have long, complicated names, and then cut and paste the name into another Kubernetes command to list the log. Brochard wanted an easier workflow that didn’t involve leaving Emacs or using the mouse. His solution is Kubernetes mode.

What I really like about the talk is that he incrementally builds up his solution in much the same way that Kris Jenkins did when building his Spotify client. He starts in the shell showing us how to call Kubernetes to list the pods and get the logs, then he writes a bit of Emacs code to call the code and put the results in a buffer using shell-command-to-string, and then split-string to get a (Lisp) list of pods.

Next he wants a way of picking the correct pod. I probably would have used ivy-completing-read or one of its brethren but Brochard chose to use tabulated-list-mode, which makes sense for him because he is going to derive Kubernetes mode from tabulated-list-mode. By combining this with his previous code to get the list of pods, he has a naive version of the desired workflow. The problem is that large files can hang Emacs while they’re being collected and, of course, trying to tail and follow the log will lock everything up. He solves that by substituting call-process and start-process (depending on whether he wants to tail or not) for shell-command-to-string. Now he a workflow with good performance and that supports tailing the log.

Finally, he uses transient from Magit to wrap his mode up in a nice UX. Again, he does this incrementally so you can follow each step.

All his intermediate code is in code blocks in an Org file so it’s easy to follow along or go back afterwards to clarify something you missed. He also has a link to the full implementation of the mode if you want to see everything together or try it out. As I said, this is a really good talk and definitely worth watching. It’s about 33 and half minutes long so plan accordingly.

Darwin Wu has an interesting post on the pros and cons of Emacs. I disagree with some of his conclusions but he does a good job of presenting a balanced view. As for the disagreements, I don’t say I’m right and he’s wrong, only that I disagree. You should read the post and make up your own mind.

His list of pros is:

• It’s fast
• Has a large number of packages
• You can Navigate from the keyboard but don’t have to
• Multiple files in a single frame

As most of you know by now, I’m all in on Emacs but I wouldn’t list “fast” as one of its strengths. The fact that Wu does makes me wonder what Atom and VS Code are like. I’ve always assumed that their architecture would make them a bit sluggish but they must be worse than I thought if they make Emacs look fast.

The other pro that I strongly disagree with is that Wu thinks it silly to have packages that allow you to do things like email in Emacs. I’m a live-in-Emacs guy and my complaint would be that I can’t do enough in Emacs. But again, different strokes for different folks.

His list of cons is:

• High learning curve
• The extensive customizability makes pair programming difficult
• Documentation is scattered about and some of it is out of date
• Too many package repositories

It’s true, of course, that mastering Emacs can take years but I’m a bit skeptical that becoming proficient with Emacs is much harder than any other editor, especially if you make use of the menus.

As for making it hard to pair program, my thoughts are best left unstated in case there are children present. I can’t imagine why anyone would care—even a little—about this.

I don’t understand his concern about documentation. There’s a lot of it, of course, but it’s all right there in Emacs. I’ve always considered documentation one of Emacs’ strengths. I’m also a bit confused about his concern that there are too many package repositories. Org-mode has its own—although it’s also available from elpa.gnu.org—but other than that there’s really only elpa.gnu and Melpa (I don’t think Marmalade is still active). As for elpa.gnu being the single source of truth, that’s laughable. I get almost all my packages from Melpa and so does everyone else I know.

I did a lot of carping in this post but Wu’s post is good and will probably be useful for those trying to decide if they want to take the plunge. As I said, read it and see what you think.