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.

How to include material after the letter in newlfm 25 November 2018

TL;DR: If you want to include additional material after the closing of a newlfm letter, forget the builtin \restletter commands. Add \newcommand\closelfm{\closlfm\let\closlfm\relax} to your letrinfo.tex file, put \closelfm where you want to end the letter (optionally followed by a \newpage), then write the additional material using standard L^aT_eXmarkup.

I use the newlfm L^aT_eXpackage for all letters I write, personal and professional. It has some nice advantages over the standard letter document class: you can have a database of different sender and recipient addresses, signatures and letterheads; it's easy to create custom letterheads that include images; you can have the correct letterhead and signature selected automatically based on sender or recipient. And many other features I don't make use of.

I have a love-hate relationship with this package, though. It has some quirks/bugs, especially to do with page layout and spacing. And whilst the documentation is extensive, it's not always the clearest. Whenever I need to do anything slightly different to what I've done before with newlfm, getting it to do what I want typically involves hours of effort and frustration the first time around, and I often ending up resorting to ugly kludges to get the letter written without wasting too much time. (This probably says more about my limitations, than those of the package.) Nonetheless, once you have a letter layout configured just the way you want, writing new letters with the same layout with newlfm is a breeze.

I was recently writing a cover letter to accompany the revisions I was submitting to one of my research papers. I wanted to attach the detailed response to the referees' comments after the letter (which contained a lot of maths so was best written in L^aT_eXtoo). The easy thing would have been to write the cover letter using newlfm, write the review response as a separate L^aT_eXdocument using some other document class, and stitch the two PDFs together using the pdftk command-line tool (or similar). But having to write these as two separate documents bugged me. I was already writing the cover letter in L^aT_eX. Why not just write the detailed referee response in the same L^aT_eXdocument?

Why I (used to) use TMDA 16 July 2005 Mine is a sad and familiar story. I was drowning in a deluge of spam (a.k.a. junk email), and it had become such a problem that email was fast becoming useless for me. Having to sort through and delete hundreds of spam emails per day was bad enough. Worse was the increasing frequency with which I was accidentally deleting legitimate email along with the spam.

There are various ways to fight this deluge of spam. The most common is to use a filter that tries to recognise and delete the spam (or, more usually, move it to a spam box for later perusal). This is quite effective. A small amount of spam will not be recognised as such (false-negatives), and will end up in your inbox anyway. But the amount of spam will usually be cut down to a manageable amount, rendering email usable again.

The problem with the filtering approach is the false-positives: legitimate mail that gets mis-identified as spam. Even if it's moved to a spam box rather than deleted, when you're searching through hundreds of spam emails you're almost certain to miss the one or two legitimate mails hiding amongst them, and you'll delete them along with the spam. (At least, that's what I found myself doing.)

A second approach is to use techniques such as domain blocking, real-time blacklists, and other methods of blocking whole groups of addresses known to send spam. But this is really just a variation on filtering (filters usually take the sender's address into account when deciding whether an email is spam or not, as well as the body).

I didn't want to run the risk of someone sending me an email, me deleting it accidentally, and them never knowing that I didn't received it. So I chose to use a third approach: white-list plus challenge/response (plus a number of other features of the impressive TMDA system).

Emailing me