Evil cursor model 18 February 2021 Updated 19 March 2021

I recently got enticed by Vim's text editing model, and began my own personal descent into evil-(mode): the full-featured Vim implementation within Emacs itself.

However, even viewed purely as a text editor, Vim doesn't get everything right in my not-so-humble opinion.

The cursor in a text editor indicates the location where the next editing operation should act, both visually to the user and internally to the text editor. There are two conceptually different ways to model the cursor location. You can consider the cursor to be located in between two consecutive characters. Or you can consider it to be located on top of a particular character. Emacs, like almost every other text editor, uses the first model. If the cursor is at location 3, say, Emacs considers it to be between the 2nd and 3rd character in the text. Typing a character will insert it in between these two characters; deleting backwards will delete character 2; deleting forwards will delete character 3.

Vim also uses this cursor model in insert mode. But in normal mode, it uses the other cursor model: if the cursor is at location 3, in normal mode Vim considers it to be located on top of the 3rd character in the text. There are therefore two insersion commands: i will start inserting text just before the 3rd character (i.e. in between characters 2 and 3); a will start inserting text just after the 3rd character (i.e. in between characters 3 and 4). Similarly, p pastes text before the character under the cursor, whereas P pastes it after that character.

I think Vim got this one wrong. Having to keep two different cursor models in mind adds cognitive burden, for little gain.

Descent into Evil 13 February 2021

I've been using Emacs for over 20 years, ever since a friend at university persuaded me to install Linux and pointed me to Emacs as a text editor. In all that time, I've never used Vim. I was never religiously opposed. More an accidental Emacs zealot, through trying Emacs first and never having any particular reason to remove myself from the category of people who have to look up the most frequently asked stackexchange question of all time when they run crontab -e under a new user without remembering to first set EDITOR.

But a few months ago, on one of those random internet walks where you start off looking up the Artin-Wedderburn theorem and, half an hour of link-following later, find yourself reading an article on worm composting without any idea how you got from one to the other, I found myself reading the Vim manual.

I already knew about the model editing and hjkl keybindings. But Vim's composable commands had completely passed me by. This notion of Vim as a text editing language, composed of "verb" operators and "noun" motions or text objects, intrigued me. Over the following weeks and months, I found myself reading ever more blog posts and articles discussing the philosophy and design of Vim.

However, there was one thing I was never going to do. No matter how elegant the philosophy of Vim's editing commands, swapping Elisp for Vimscript was a Faustian bargain so offputting, I wasn't even tempted to fire up Vim itself out of curiosity. But there's a Goethian Gretchen to Vim's Mephistophiles: evil-mode – an implementation of Vim within Emacs itself.

Thus began my descent into Evil.

Lost or corrupted undo-tree history 6 January 2020 Undo-tree is the most popular of the Emacs packages I wrote and maintain, not least because it's used by Evil and Spacemacs. However, for many years, the internet has been awash with reports of undo history being lost or corrupted when using undo-tree-mode. Trouble was, though I do all my text editing in Emacs, and always have global-undo-tree-mode enabled, I'd never encountered these issues myself. And no one had ever been able to send me a recipe for reliably reproducing them. Making it fiendishly difficult to even begin to investigate what might be going on.

This post is about some recent changes to undo-tree that might finally address these issues.