Irreal

Correl Roush has a very nice post that beautifully illustrates the idea of writing code to write code. It’s a tremendously powerful idea because it lets you leverage some other program or programming language to do a task that requires specialized knowledge to code or is otherwise too hard to do directly. Examples that I’ve used are writing code to generate troff source as an intermediate to producing typeset output and code to generate graphviz source as an intermediate to generating a graph.

Roush gives us a nice example of generating graphviz (dot) source code to produce a nice looking graph. The particular problem she’s addressing is building a tool that you can point at a git repository and have it produce a nice graph of the commits. That seems unreasonably hard if you approach the problem ab initio but is very tractable if you leverage git and graphviz to do the hard work. Git can produce a topologically sorted list of commits and graphviz can do all the drawing of the graphs. All Roush has to do is add some glue code.

Roush decided to work in elisp and builds up her application step by step. She starts by showing the dot input she wants to produce and then writes the code to produce it. By iterating through more complicated graphs until she gets the final result, she shows to build the application iteratively, a programming method that I especially like.

I also like the way Roush uses data abstraction. Her list-based implementation may or may not scale to huge git repositories but her use of data abstraction makes it almost trivial to move to a more efficient implementation if required.

One of the things that’s harder than it should be in Emacs is embedded shells. You can type Meta+x shell and sort of have a shell. Except it doesn’t work very well. There are other options but it can be really confusing for the n00b or even a semi-experienced user not familiar with invoking shells from Emacs.

Derek Taylor has a video that explains and compares Emacs shells. He—rightly in my opinion—rejects the shell and ansi-term command as basically unusable for non-trivial commands. Until fairly recently there wasn’t a good solution if you wanted a traditional shell.

As Taylor says, that has recently been remedied by the introduction of vterm. It requires the relatively new module system but solves most of the problems for those who want to have a “normal” Unix shell. It solves all the problems with shell and ansi-term and lets you run a full-function shell from within Emacs.

But that’s not all, of course. There’s also eshell. It’s both less and more than a Unix shell. Some things don’t work as well but eshell has capabilities well beyond those of traditional shells. Taylor demonstrates some—but not all—of those capabilities. There are others that he doesn’t demonstrate.

The video is 17 minutes, 20 seconds long—a bit shorter if you skip the shoutouts at the end—so you’ll have to schedule some time. If you’ve been confused by Emacs shells, take a look at Taylor’s video. It’s a good summary.

The title almost sounds like something you’d see headlining a parody but it turns out that a medievalist using Emacs is really what this post is about. Joseph R. Johnson is a medievalist at Georgetown who spends a great deal of his time transcribing medieval texts.

That’s harder than you might think—if that’s possible—because different scribes produced subtly different renditions and because they used a lot of abbreviations similar to present day contractions (like “don’t” for “do not”) but not as deterministic as today’s contractions. Johnson’s post has an example that shows how complex those abbreviations can be.

Because the abbreviations can be ambiguous, Johnson puts the letters that the diacritical marks represent in parentheses. An example is v(ost)re where the “ost” in parentheses is represented by a diacritical mark. The problem is that all those parentheses were hard on his hands and he was worried about RSI (he should try Lisp).

The point of this long story is that Johnson is an Emacs user who took the time to learn a little Elisp so that he could leverage its power to ease his transcribing. He implemented an Emacs minor mode that implements easy to type shortcuts that save him from having to type all those parentheses. The post shows several iterations of his efforts.

I love stories like this because it makes the important point that if you deal with text you should be using Emacs. As others have said, Emacs is not so much an editor as it is a framework for dealing with text. That may include editing but it also includes things like email, RSS, playing music, and who knows what. As most of you know, I think of Emacs as a lightweight Lisp Machine, which means, of course, that you can program it to do almost anything. Johnson’s use of Emacs to help his transcription of medieval texts is a case in point.

I’ve written a few times about gccemacs (1, 2, 3) and what it means for the future of Emacs. The good news is that it’s being merged into the Master branch and with any luck will make its first official appearance when Emacs 28.1 is released.

In the mean time, the more adventurous can try things out by compiling the development version of Emacs 28 from its Git repository. Of course, Emacs 28 is still very early in its development cycle and is not stable. Still, if you just want to try it out or have a particular need for the speed boost, there’s no reason not to try it out.

Luca Cambiaghi really needs the speed so he’s compiled the macOS gccemacs repository for his everyday use. He gives a detailed explanation of his steps and the problems he found. If you’re on macOS and want to try out gccemacs, his post is a good resource. I’d be hesitant to use it for anything other than experimentation or tire kicking—although Cambiaghi appears to be using it as his working version—but if you want to see what all the excitement is about, follow Cambiaghi’s recipe to try it out. He also has something to say about Doom Emacs so if you’re interested in Doom, you should also check out his post.

No. Of course not. The commentary one sees on Emacs is much like that one sees for Apple: This latest [smartphone | editor] is an [iPhone | Emacs] killer. Besides, the iPhone/Emacs is old, tired technology. It’s doomed. And yet, both seem to not only survive but thrive.

Oivvio Polite has a personal take on the question. He started using Emacs in 1999 so his views are informed. Oddly, his major complaint is that Emacs users have to build the editor they want by themselves. I, and many others, have always considered that one of Emacs’ advantages. Certainly, I never considered it an imposition when I started with Emacs. I began with vanilla Emacs and added the bits I needed for C, Lisp, and Scheme. It all seemed natural and unintimidating. The introduction of the package system made things even easier.

Still, some people prefer an “out-of-the-box” experience and aren’t interested in building their own. As usual, Emacs has you covered. If you want a light-weight solution, there are several starter kits such as Bozhidar Batsov’s Prelude or Steve Purcell’s Emacs configuration. If you want a more comprehensive solution, there are the Spacemacs and Doom distributions. A lot of folks think Spacemacs and Doom are for immigrants from Vim but as Derek Taylor says, sometimes n00bs use Spacemacs and Doom because they’re easier.

Polite is not a n00b but he does like Doom and thinks it points to the way forward for Emacs. I agree that they’re a real boon for some users but continue to believe that vanilla Emacs has a long and bright future. Take a look at Polite’s post for his views and see if you agree.