Irreal

As many you know, I was a Vim user for a couple of decades before I found the one true editor. One of the things I miss from Vim is the easy to use repeat command. If you’re in command mode and perform some command, you can repeat that command by simply pressing .. Sadly, Emacs doesn’t have anything similar. There are a couple of repeat commands: one for simple commands and another for “complex” commands but I was never able to internalize them.

Happily, there is repeat mode that allows you to repeat a command by omitting the prefix and pressing the last key. For example, if you want to repeat the command to enlarge a window horizontally (Ctrl+x }) you can simply repeat the } as many times as needed.

As Bozhidar Batsov explains, this doesn’t work with every key sequence but it is easy to add the functionality to multikey sequences. The TL;DR is that you have to provide a special keymap that maps the last key(s) to their action(s). Batsov has a worked example to show you how to do it. It’s not very hard. But, it turns out, it can be even easier. Omar Antolín explains in a comment that there is also a macro, defvar-keymap that abstracts all the boilerplate away and makes it really easy to define and install a new repeat map.

Repeat mode still isn’t as nice as Vim’s repeat but it can reduce the friction of repeating certain commands. Take a look at Batsov’s post for the details.

Update [2026-04-06 Mon 11:05]:

Karthik Chikmagalur has an excellent write-up on repeat mode that shows it’s useful for much more than simply repeating a command. See his comment below.

Irreal readers can’t help but know who Álvaro Ramírez is, if for no other reason that I’m always blathering on about his Journelly app that is my most used and useful iOS app. But of course, Ramírez has many other excellent apps, many of which are Emacs packages. In particular, there is his dwim-shell-command that allows you to automate shell commands—particularly those with complex invocations—from the comfort of Emacs. There’s also his take on music players, an uniform AI access app, and a lot more besides.

You can check out his blog posts or take a look at his iOS/macOS/Emacs applications. He’s been an independent developer for some time but now he’s taken on a new role: fatherhood. He’s now the proud dad of a new son. He tells us that his output may slow down a bit because, after all, he has to start working on his son’s init.el.

There are, I suppose, a few Lisp programmers using Emacs who resist paredit but most of the rest of us have long since succumbed to its charms. It can be a bit difficult to get used to but once you do, it’s a tool you don’t want to live without.

There is a problem though. Since Paredit’s introduction 20 years ago, Emacs has added new default keybindings some of which conflict with the existing Paredit keybindings. I can remember having to remap some of Paredit’s keybindings to avoid this.

Bozhidar Batsov has a nice post that discusses these conflicts and how to deal with them. My use of Paredit is mostly restricted to a small subset of its commands so I haven’t experienced the full impact of these conflicts. Even for those commands I do use—like slurp and barf—the conflict doesn’t bother me because I never use the arrow keys to move the cursor.

If you use more of the Paredit commands, take a look at Batsov’s post for his suggestions for resolving them. Or, you could switch to Fuco1’s smartparens, which avoids these conflicts while providing the same functionality and extending it to other file types.

One thing for sure, if you use paredit-splice-sexp you’ll want to resolve its conflict because Emacs uses Meta+s as the search map prefix and that is too useful to forego.

In any event if you’re a Paredit or Smartparens user, you should definitely take a look at Batsov’s post.

One of Lisp’s features that seem like magic to those of us brought up with C-like languages is the ability to change the code of a running process, reload it, and continue running with the new code. The amazing thing is that the process is not restarted. It simply continues running but with the new code.

Emacers do this all the time, often without realizing what they’re doing. They make a change, to their init.el, say, evaluate it, and continue executing their current Emacs instance. Sometimes, this is simply changing a parameter value but you can also change a function definition in the same way.

If you’re new to Emacs you may wonder how this magical spell is invoked even though you’ve done it several times. It’s simply a matter of evaluating the new code and continuing. Except when it isn’t. There are some edge cases that can trip you up. In Lisp it’s devar values. Emacs adds defface and defcustom. The values defined by these commands are not changed by a code update. This is on purpose. The idea is that you don’t want to mess with a user’s, say, custom values when you change the code.

Bozhidar Batsov has a nice post that discusses all this with particular attention on how to deal with devar and the other edge cases. For example, I always thought the the way to change devar variables was to evaluate a setq of the variable with the new value but you can also simple invoke eval-defun (Ctrl+Meta+x) to the devar to update the value. This also works for defcustom and defface.

The other nice thing I didn’t know about is the restart-emacs command that restarts Emacs and—with desktop-save-mode​—reloads everything, including the new defvar etc. values. Take a look at Batsov’s post for more details.