Irreal

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.

Bozhidar Batsov over at Emacs Redux, has got another useful bit of Elisp to help clean up packages that may not have been compiled correctly. This sometimes happens to me when I update a package with package.el. The idea is to unload the function, reinstall it, and then load it again.

Batsov’s packages his Elisp as a simple function. It’s not especially user friendly because it can’t be called interactively so he provides another function that you can call with the usual Meta+x mechanism and choose the package through the completing-read function.

As Batsov says, this probably isn’t something that you’re going to need very often so you might not want to clutter up your configuration with it if you worry about such things. Even if that’s the case, you can just call the three commands separately. The require function isn’t interactive but it’s easy to call from the minibuffer with eval-expression, usually bound to Meta+:.

If you’re the type of person who hates to restart Emacs, this can be an easy way to resolve update problems without having to start over with your Emacs instance. I’ve added the interactive version to my config but haven’t needed it yet. We’ll see how it goes.

Emacs users on macOS are always discovering that the operating system supports many of the Emacs navigation keybindings and share their discovery with a Tweet or reddit post. Of course, it’s much better than that. You can install most of the Emacs editing keybindings into macOS. I first wrote about this 9 years ago and have periodically repeated the information as more and more folks discover the default Emacs bindings in macOS.

I thought that by now I and others had said everything worth saying about the matter but Álvaro Ramírez has something else interesting to add. It turns out the Ctrl+n and Ctrl+p don’t work correctly in macOS system completion lists. Ramírez has internalized the Ctrl+n and Ctrl+p bindings, especially since they work everywhere else, and was bothered by the failure on completion lists.

Ramírez found a solution from Atif Afzal. The TL;DR is that he uses Karabiner-Elements to map Ctrl+n and Ctrl+p to the down and up arrow keys. Take a look at Ramírez’s post for the details including the karabiner.json to make the mappings. He also includes a configuration to map Ctrl+g to Esc, which he finds to be useful as well.