Irreal

Over at Linux User Space, Leo and Dan have a short video giving a reasonably comprehensive history of Emacs:

Would you look at that! Another text editor #history hitting @tilvids today.

This time, it’s #Emacs.

Oh, you didn’t know #TECO preceded it? Well, you do now.https://t.co/Y5Qzpb6LX9

— Linux User Space (@LinuxUserSpace) February 16, 2023

They start with TECO and the infamous tower of Babel that grew out of every developer having their own set of macros leading Guy Steele and Richard Stallman to develop a standard set of Editing MACroS that everyone could use. From there, they trace Emacs’ development from a set of TECO macros to the current day GNU Emacs. Along the way, they discuss Gosling Emacs and its relation to GNU Emacs as well as the Lucid version that eventually became XEmacs.

The video is 14 and a half minutes long so it shouldn’t be too hard to fit in. If you’re freaked out by the warning about leaking your IP address in the Twitter link, just follow the above link and watch it on YouTube.

Vivek Haldar is a Python fan and considers Guido von Rossum “one of the best language designers of our time.” He was surprised, therefore, when von Rossum suggested in a Lex Fridman podcast that VS Code was the spiritual successor to Emacs. For many of us, that’s like lighting a stick of dynamite under our chair but Haldar considers the idea of VS Code being the spiritual successor to Emacs calmly and rationally.

Not surprisingly he disagrees. Von Rossum bases his assertion on the fact that VS Code and Emacs are both structured as an interpretive language engine at the core and the majority of the editor implemented in that language. In Emacs’ case, that language is Lisp. In VS Code’s case it’s JavaScript. Theoretically, that makes them both highly extensible but there’s a difference.

Haldar says that Emacs has two things that VS Code doesn’t:

Barrier-less extension

The idea that you can write some Elisp anywhere in Emacs, mark it, execute it with Meta+x eval-region, and have the effects take place immediately. If you like the changes you can add the code to your init.el and have its action take place every time you start Emacs.

Everything is a buffer

I’ve written about this before. As Haldar says, it basically means that whatever you do in Emacs, it’s in a buffer and subject to the usual Emacs editing and manipulation functionality.

I’d add a third Emacs advantage: Emacs is Free Software and not owned by anyone. I say that not as a true believing ideologue but as someone who’s been around long enough to know how Microsoft operates and to not trust them or their intentions. I worry that Microsoft will eventually revert to type and pull the rug out from under VS Code users.

In any event, Haldar reaches the same conclusion that I do: VS Code is not the spiritual successor the Emacs.

Yesterday I wrote about T V Raman’s post explaining how he uses the X Windows xcape command to provide extra keys and better ergonomics for Emacs. Raman has some nice ideas about improving the Emacs keyboard interface but they were, unfortunately, restricted to those using X Windows. That’s a lot of people, of course, but about a quarter of those who use Emacs are doing so on a Mac and Raman’s hack wasn’t available to them.

Jeremy Friesen to the rescue. Like me, he was intrigued by Raman’s post but unlike me he decided to do something about it. He had a head start because he’s a Karabiner-Elements user and Karabiner makes it easy to do the sort of thing described by Raman.

Take a look at Friesen’s post for the details. Not everyone will want to do this but if you think your workflow could benefit from overloading modifier keys to provide additional shortcuts and eliminate some chording, it’s nice to know it’s possible for Mac as well as X Windows users.

T V Raman has a post that may be interesting to those of you who run Emacs under X. That’s probably just about everybody who isn’t using a Mac so many of you may be interested. The TL;DR is that his method turns the modifier keys into what he calls buttons. For example, (with his setup) pressing (just) the Ctrl key will send Ctrl+e to Emacs.

His keyboard has three modifier keys on each side of Space and adding the two Shift keys gives him eight possible “buttons”.

The key to making this work is the xcape command in the Xorg keyboard configuration to define what each of the buttons produce. Raman links to his xcape and XModmap configurations so you can see how he set things up but you’ll probably prefer other mappings.

The advantage of Raman’s method is two fold:

1. It avoids chording for commonly use commands.
2. It gives you several (8 in Raman’s case) extra keys to do something useful with.

If you’re an X user and interested in improving your keyboard ergonomics or perhaps just gaining some useful shortcut keys, take a look at Raman’s post. If you’re not afraid of modifying your XModmap file it’s not hard to set up.

UPDATE [2023-02-17 Fri]: Added link to Raman’s post.

Nicolas Martyanoff has a post on something I didn’t know about: Emacs Tempo templates. I’ve been an Emacs user for somewhere between 15 and 20 years and I’d never heard of Tempp templates. On the one hand that’s pretty surprising. On the other hand, we all know that learning Emacs is a lifelong journey that is never completed.

As most of you know, I’m a Yasnippet user and find it very useful even for non-programming chores so I’m not in the market for another templating engine but if you’re new to templating, Tempo may be worth a look. I don’t have any experience with it, obviously, but based on Martyanoff’s description I’d judge that Yasnippet is easier to use and learn and seems more flexible too.

Martyanoff says that one of the virtues of Tempo is that it’s simple but I find it harder to use than Yasnippet so my advice to the template n00b is to use Yasnippet. Still, as always, Emacs let you have your way. Along with skeletons there are three¹ template systems you can use with Emacs so there are plenty of choices.

Here’s some good news: The F-Droid site now has a more or less complete implementation of GNU Emacs for the Android platform. I’m not sure Emacs on a phone is all that useful other than for dealing with Org files and there are several apps already available for that on both the Android and iOS platforms. On a tablet, though, it could be a real game changer. Emacs on a tablet—perhaps with a real keyboard—would enable truly remote work. Yes, you can carry your laptop around as many of us do but a tablet is much easier especially in situations such as air travel.

We here at Irreal are famously iPhone/iPad users so F-Droid’s announcement doesn’t affect us directly but perhaps it will encourage Apple to relax their no interpreters rule on the platform. I understand their reasoning but having a workable Emacs on the iPad would be such a win that it would be worth it, especially with appropriate sandboxing.

If we had Emacs on the iPad it would change my mobile computing strategy completely. I’d get a good keyboard for the iPad and probably almost always leave my laptop at home. The iPad, modulo software, is already as powerful as many laptops and could easily support remote work. I have a family member—in banking not software—who already uses his iPad as his exclusive mobile device. There’s no reason we developers couldn’t do the same. All we need is Emacs. I love my laptop and don’t foresee myself ever giving it up but it sure would be nice to have an easy-to-carry device for remote work.