M-x apropos Emacs

One of my most common typos is being slow to release the shift key and accidentally capitalizing the first two letters of a word, as in “See you next THursday!”. When I make that mistake I often notice it before I finish typing that word and in stock Emacs I could fix it right away with M-- M-c or M-b M-c. (By default M-c is bound to capitalize-word, but I recommend rebinding it to capitalize-dwim which acts as capitalize-word unless there is an active region in which case it acts as capitalize-region.) At some point I noticed that my most common use of M-c was to capitalize the previous word, and decided to simplify that case. Initially I wrote a command that is just like capitalize-dwim except that if point is at the end of the word it acts on the previous word rather than on the next one. That did simplify my most common usage of M-c but it introduced a new problem: when I wasn’t fixing a typo in a word I just entered, I often forgot the new behavior and expected M-c to capitalize the next word, even if point was at the end of a word; in those cases my new command annoyed me quite a bit.

This illustrates what I feel is an underappreciated point: the user experience (UX) of even simple editing commands is often tricky to get exactly right. Of course, people are aware that UX design is hard, but I think people tend to assume it’s only hard for larger programs, not for something tiny like capitalize-word. But for a command you are likely to use many times a day getting the UX exactly right really pays off. I eventually fixed my command drawing inspiration from a different set of commands that are also extremely useful while writing prose: the tranpose family of commands. I’ll explain the feature of these commands that I adopted for the case change commands, after I explain what they do. The transpose commands are fantastic and I don’t understand why not every editor has them (even Vim doesn’t!). Another extremely common typo I make is swapping two charcaters. To fix that, you put point on the second of the characters (if your cursor is a bar, put the bar between the swapped characters) and use transpose-chars, bound by default to C-t. There are also tranpose-words (M-t), transpose-sexps (C-M-t), transpose-lines (C-x C-t), transpose-sentences and transpose-paragraphs. The sexp and line commands are more useful for editing code than prose, but are still useful for prose, particular since parenthetical expressions or quoted text count as sexps. It’s a little sad that the sentence and paragraph commands are not bound by default; I bind them to M-T and C-x M-t respectively. While transpose-chars is most useful for fixing typos, the other transpose commands are more useful while editing. I find I rearrange text quite a bit: Even for a 5−10 line email I’m fairly likely to have swapped two sentences or even two paragraphs while writing it!

The transpose family of commands have a few very nifty features:

1. They leave point after the second of the two swapped things, which means that by simply repeating the command you can continue to move that thing to the right. With a negative prefix argument you can drag things to the left instead.
2. With a prefix argument of 0 they can swap non-adjacent things! Select a region starting somewhere in the first thing and ending somewhere in the second and call a transpose command with a prefix argument of 0 to swap them,
3. If you use transpose-chars at the end of a line you might think it would swap the last character of the line with the newline, since, that newline is after all the next character, but instead it swaps the last two characters on the line. This means that if you accidentally swap two characters while entering text (at the end of some line) and notice the typo immediately, you can fix it with just C-t without moving the point! This is special behavior of transpose-chars, sadly not shared by transpose-words, but at least that one has a similar but lesser magic: if you use transpose-words at the end of the buffer (yes, I said “buffer”, not “line”), it will… not swap the last two words, but produce an error message. and also move point to before the last word. But that very last bit means that a second M-t will swap the last two words! OK, kind of lame compared to C-t but at least it’s something.

That last behavior of transpose-chars is what I adopted for my versions of the case-change dwim commands: if you call one of my case-change commands at the end of a line, it changes the case of the last word of the line (not the first word on the next non-blank line, which is what capitalize-word or capitalize-dwim would do). And that feels perfect to me: my common typo is fixed with a simply M-c but while editing text in the middle of the text I don’t get any unpleasant surprises anymore. Try teaching that to a web browser text input box!

Another tiny annoyance I had with the built-in commands is that the marking commands only mark from point to the end of the thing they are for. For example mark-word does not mark the word at point, it marks the portion of that word starting at point (so if point is on the first character of the word, it does mark the entire word). The analogous command for sentences has more honest name: mark-end-of-sentence ―though mark-to-end-of-sentence would be even clearer. Now, for sentences, that behavior seems fine and useful to me, since I often do want to grab just the tail of a sentence, but I basically never want to mark just a piece of a word. So I wrote a command that marks the entire word point is on, bound it to M-@ and just use it in place of mark-word. Obviously I called my command mark-my-word.

That mark-end-of-sentence command I mentioned doesn’t have a default key binding, but that’s OK since you can achieve the same effect by using shift selection with the forward-sentence command (I mean typing M-E). But there are some very useful commands, particularly in the misc.el library, with no key binding:

• zap-up-to-char, which I find I want more often than zap-to-char, so I bind this one M-z and zap-to-char to M-Z.
• forward-to-word and backward-to-word which move to the opposite end of the word than forward-word and backward-word do; I bind these to M-F and M-B.
• copy-from-above-command and duplicate-dwim, two commands that can duplicate a line. The first duplicates the line above point and the second duplicates the line at point. The first command actually duplicates the tail of the line above starting from the current column, and if given a numeric argument will only duplicate that many characters (I hardly ever use this last bit of functionality since I find counting characters tedious and error prone). The second command will duplicate the region if it is active ―which is what dwim means in several Emacs commands.
• delete-forward-char is a surprising one: by default C-d is bound to delete-char but the documentation for that command says: “The command ‘delete-forward-char’ is preferable for interactive use, e.g. because it respects values of ‘delete-active-region’ and ‘overwrite-mode’.” I agreed and rebound C-d.
• kill-paragraph, I bind this to M-K.
• up-list moves you out of a delimited expression, which honestly is more useful when writing code, but I mention it here since I do use it often for getting out of parenthetical remarks or quotation marks. I bind to C-M-o which goes well with the other sexp navigation commands with C-M- modifiers; the mnemonic for o is that it gets me Out of a sexp.
• transpose-sentences and transpose-paragraphs I already mentioned above. I bind them to M-T and C-x M-t. In org-mode buffers you don’t really need transpose-paragraphs since M-<down> and M-<up> cover its functionality.

The kind of “autocompletion” I almost always want while writing prose is simply to complete text I’ve already typed somewhere. For that dabbrev-expand (bound to M-/) is super useful: it’ll search for completions of the beginning of a word you’ve typed in several places in order: the current buffer before point, the current buffer after point, other buffers in the same major mode as the current buffer, and finally all other buffers. (That’s just the default configuration, as usual in Emacs, dabbrev is quite configurable.) I often find myself opening some file just so I can complete words from it in another buffer. One lesser known feature of dabbrev-expand is that you can also use it to complete phrases, not just words: if right after completing a word using dabbrev-expand you insert a space and then run dabbrev-expand again, it will insert the word that followed the first word wherever it found it. So M-/ SPC M-/ SPC M-/ ... will complete a phrase from your buffer. To make this even more convenient I wrote this little command that I bind to M-;:

(defun dabbrev-next (arg)
  "Insert the next ARG words from where previous expansion was found."
  (interactive "p")
  (dotimes (_ arg)
    (insert " ")
    (dabbrev-expand 1))
  (setq this-command 'dabbrev-expand))

That way I can complete a phrase with M-/ M-; M-; .... You can really fly that way. For example, the previous paragraph says “current buffer” three times; I only wrote the first one in full, the others were cur M-/ M-;.

This one isn’t so impressive to computer programmers, used as they are to source control, but let me tell you that the ease with which you can merge versions of files using ediff will absolutely blow mathematicians minds! I’ve impressed several coauthors by merging our changes to a draft paper in less than a minute, flying over changes faster than they can orient themselves. It feels like a super power to people who haven’t seen something like it before.

I don’t think it would surprise anyone to say that keyboard macros are very useful for automating edits while coding, but perhaps it is a little surprising they can also be very useful while editing prose. One thing that comes up fairly often for me is that I want to write a bulleted list and I have the raw data I need to talk about in some other format. For example I might have a spreadsheet (if it’s shared) or an org table (if I’m the only one editing) with a list of names, email addresses and affiliations of some people and I need to write a small paragraph about each person. Here’s an example with fake people:

And I want to turn it into:

• Juana Sinisterra <jsinis@uni.junco> from Universidad del Junco, XXX.
• Molly Edwards <medwards@henkin.edu> from Henkin College, XXX.
• Mario Finetti <mfino@vallebruna.it> from Universitá di Vallebruna, XXX.

where the “XXX” are placeholders I’ll fill in later. (I’d actually use <++> as the placeholders and fill them in using my placeholder package, but never mind that now.) For this I’d record a keyboard macro that transforms a single row of the table and just run it for each line. For dealing with keyboard macros I prefer the “modern” interface, consisting of kmacro-start-macro-or-insert-counter (bound to <f3>) and kmacro-end-or-call-macro (bound to <f4>), which can be used in place of all four of these “old” key bindings: C-x (, C-x C-k C-i, C-x ) and C-x e. However I find the function keys a little too far for comfort, so I rebind the commands to M-r (for “record”) and M-m (for “macro”). (M-m is bound by default to back-to-indentation, a command which I do use but rebound to the more mnemonic M-i; M-r also has a default binding, but I never use that command). Since I switched to the simpler “modern” macro commands I find that I use keyboard macros a lot more, and rebinding them to the highly accesible M-r and M-m keys gave my macro usage a further boost.

In the example I gave above, I wanted to run the keyboard macro to every line of a table. You can do that by recording the macro, marking the remaining lines and using apply-macro-to-region-lines bound to C-x C-k r. That key binding is a little awkward and to be honest I don’t use it: Embark binds that command to m when you are acting on a region, so I use C-. m (simpler key bindings are a nice perk of Embark’s contextuality). But there is further convenience to be enjoyed: as in this example, I very often want to apply a macro to every line of a “paragraph” (a table with a blank line after it counts), or rather, to the remaining lines of a paragraph after recording the macro for the first line. For that I wrote this simple command I bind to M-M:

(defun apply-macro-to-rest-of-paragraph ()
  "Apply last keyboard macro to each line in the rest of the current paragraph."
  (interactive)
  (when defining-kbd-macro (kmacro-end-macro nil))
  (apply-macro-to-region-lines
   (line-beginning-position 2)
   (save-excursion (end-of-paragraph-text) (point))))

It feels like magic: M-r, do stuff to the first line, M-M and boom, the same transformation gets applied to the rest of the lines!

In my early days as an Emacs user I simply used the default completion UI. This UI doesn’t not show the completion candidates all the time. If all the candidates have the next bit of text in common, pressing TAB inserts it into the minibuffer (people call this TAB completion). I’ve always found this funny since it makes zero progress towards choosing a single completion candidate: it only inserts as much text as will not narrow down things at all! But people like it for some reason, I guess as visual feedback that what you thought the completion candidates had in common they really do have in common. (To be fair you can configure completion-cycle-threshold to have TAB cycle among candidates when there aren’t many left.)

Pressing TAB a second time will pop up the *Completions* buffer, which shows a list of all completion candidates. From there you can click on a candidates, navigate to it and press RET, or just type some more and press TAB again to get an updated candidate list.

Don’t knock the default completion UI. It is functional, powerful and perfectly usable out of the box. But most people want to see how the available candidates change automatically as you type. The other UIs I tried all have that feature in common; they also all have a notion of the “current completion candidate”, and there is a way to select that current candidate without finishing typing it ―usually but not always this done simply by pressing RET.

Ido also comes with Emacs and is pretty funky. For one thing it doesn’t take over all minibuffer completion services, it only provides special versions of certain commands, mainly to open files and switch buffers. Those commands also enable some additional key bindings while you are using the commands: while opening a file you can press a key to delete a file, or while switching buffers you can press a key to kill a buffer. This sort of thing is called “acting on a completion candidate”, and boy do I like it ―more about this later. Ido uses fuzzy completion, where characters only have to appear in order in a completion candidate, not necessarily consecutively; for example epnf matches eww-open-file.

If you like Ido but want to use it for all minibuffer completion there are some options: there’s the ido-completing-read+ package and the built-in fido-mode. I don’t particularly like fuzzy matching since it feels inefficient to me, there are always two many matches for my taste.

Helm is a comprehensive package that not only takes over all minibuffer completion duties but comes with many commands that take advantage of Helm’s additional features. It’s big and brash and opinionated. I used it for many months and was quite happy with it. I particularly liked that the Helm commands came with many actions you could perform on the completion candidates. I didn’t much like its default aesthetics or its long load time (although since you only incur that once per session it doesn’t really matter). One thing I didn’t like much is that somehow it didn’t seem to blend in very well with the rest of my Emacs experience. For example, only commands written specially to use Helm had actions for the completion candidates, and the actions had to be implemented in a particular way, you couldn’t use any old Emacs command as an action. But all in all Helm is great, an impressive piece of software that sprouted its own mini-ecosystem of related packages.

After Helm I used Ivy and its companion Swiper and Counsel packages for a while. It felt pretty similar to using Helm to me, except I liked the default look of it better (which is not to say you couldn’t easily configure the visual aspects of Helm). It also had a notion of actions, but similarly to Helm, you needed to write them specially for each command. I think it was less batteries-included than Helm, for example I have a vague recollection of counsel-find-file, its substitute for find-file, not coming with actions to rename or copy files, which I wrote in my own configuration. It’s then that it started to bother me that I couldn’t simply say “I want the Emacs commands rename-file and copy-file as actions”, I was forced to write little wrappers for them. Like Helm, I think the Ivy/Swiper/Counsel family is great software and was a happy user. I did however, as I did with Helm, that it reinvented the wheel too much and that something like it would be possible that took more advantage of existing Emacs APIs and functions.

This is another built-in option, which I think I only started using after having used Helm and Ivy. I used it for a quite a while and still think it is perfectly workable. One thing I like about it is that, like the default completion UI, it only concerns itself with displaying the completion candidates and leaves the important matter of which candidates are considered to match the minibuffer input to the current completion styles. There is no formal notion in Emacs of a “well-behaved” completion UI, but in my head certainly such a UI should limit itself to showing you the candidates and leave the user to configure completion styles separately. This what I dislike about fido-mode: it ignores your completion style configuration and makes you use the flex completion style instead (you can change this but it requires being sneaky, not simply setting completion-styles).

One difference between Icomplete and Helm or Ivy, is that it displays the completion candidates in a compact horizontal list like Ido, instead of one per line, like Helm or Ivy. When I was an Icomplete user, I even wrote a package called icomplete-vertical that would configure Icomplete to display the candidates vertically, one per line. Nowadays there is also a built-in package of the same name which I did not write, nor does it use my code. I remember thinking the built-in package had a bug mine lacked, triggered when you switched from horizontal to vertical during a minibuffer completion session, but I couldn’t reproduce it now so either they fixed it, or I couldn’t remember exactly what the bug was, or my memory is playing tricks on me.

The mention of icomplete-vertical above is the start of an embarrassing parade of completion UIs I wrote myself, for myself and which I don’t think more than a handful people ever used. What marred all of my feeble attempts, other than icomplete-vertical which is just some configuration code on top of icomplete, was a distinct lack of speed. The idea of these incremental, automatic completion UIs is to show you how the candidate list changes in real time, but most of mine struggled to do this fast enough.

My live-completions package had a very simple idea: pop up the *Completions* buffer that the default UI uses and just update it after every key press. It let you format the completions in either a grid or a single column, back before the default UI had the single column view.

I think I used this for quite a while though it wasn’t very good. I believe that by the time I wrote this, I already had an initial version of Embark that took care of acting on completion candidates solving all of the complaints I had about actions in Ido, Helm or Ivy: Embark lets you use any Emacs command directly as an action, there is no need to write wrappers over existing commands; it endows every single command that has a minibuffer prompt with actions on its candidates, commands do not have to be written specially with Embark in mind to acquire actions.

Another bad completion UI I wrote. Hey, at least it’s small. I don’t think I used this for very long, maybe a couple of weeks. It’s called grille because it displays completions in a grid. I have nothing else to say about it.

For a while Embark included its own completions UI! This is obviously a bad idea, which I only did because it was easy, since Embark had grown to have almost all the components necessary for this. It was slow, but other than that I found it surprisingly good. It was certainly featureful: it displayed the completions either one per line or in a grid, the grid optionally with zebra stripes to guide the eye. I stubbornly kept using it until I dropped it for Vertico and finally removed it from Embark.

The excellent Vertico package is what I use now as a completion UI. The author, Daniel Mendler, and I have long worked together on a suite of packages that provide a full completion experience for Emacs. I wanted to switch from embark-completions to Vertico but held out until Daniel added a grid display to Vertico. In retrospect this was silly on my part, but I believe my stubbornness might have helped motivate Daniel to add the grid feature. Of this suite of packages, Daniel wrote Vertico, Corfu, Cape; I wrote Embark and Orderless (the latter of which we now co-maintain); and we wrote Marginalia together after noticing we were both writing something like it.

Vertico

a highly flexible completion UI, that can display completions one per line or in a grid, in the minibuffer or in a dedicated buffer.

Orderless

a highly configurable completion style, whose main feature is matching space-separated bits of the input in any order against the completion candidates; so op eww matches eww-open-file.

Embark

lets you use any Emacs command as an action on any minibuffer completion candidate or on a thing at point in a non-mini buffer; it also comes with an extensive default configuration assigning convenient keybindings to the most commonly used actions (but you can always M-x to use whatever command you want as an action!)

Marginalia

provides extra information about completion candidates of common types, most completion UIs that display candidates as one per line will shows this extra information to the right of the candidate.

Corfu

this is a completion UI for completion-at-point, which I haven’t talked about here at all ―it is the type of completion that you get when writing code in a buffer, for example. Again here I stubbornly held out a long time using my own contraption (consult-completion-in-region, which I contributed to consult).

Cape

a suite of completion-at-point functions; again I stubbornly held out using an embark-based substitute for this for a long time ―I’m starting to notice an unflattering pattern.

I already finished listing the completion UIs that I actually used for a period of time, but there are a couple of others I tried and probably some I did not try (maybe snails, though I’m not exactly sure what it is, since I’ve only every briefly skimmed its README). I tried Selectrum once and, to my discredit, only complained about some minor issues with it on reddit. At least I’m focused thematically in my complaints: I thought it wasn’t Emacsy enough, that it disrespected some Emacs variables it could easily respect. Well, that, and there something I didn’t like about its completing-read-multiple experience (I think it was that you couldn’t easily see what you had already selected). I never used Prot’s MCT package extensively, but I would call it similar in idea to my live-completions package, and would hope Prot does not disagree with this characterization. It somehow seemed smoother than my live-completions, probably because Prot had more patience tweaking the experience than I did.