Re: productivity (and lack thereof)

Fri 10 Sep 2021

This is a reply to ~emily at tilde.pink, and also Sandra’s reply at Idiomdrottning.

productivity (and lack thereof)

Re: productivity (and lack thereof)

I’m never sure if I should recommend Emacs to other people who want to improve their productivity, or at least their efficiency with editing text. I’m coming up on 30 years of Emacs use in a few months, it’s deeply wired not only into my muscle memory, but also the way I think about problems and user interfaces. The way I use it has changed a lot over that time, and keeps changing, so it’s not all a matter of sunk cost.

The way I see it, there are a number of different use cases for Emacs usage, and they’re not all definitely self-justifying.

The stages:

Ordinary text editing

You want to make normal changes to text files: insert and delete text, cut, copy, and paste things, type new stuff. Maybe you want a little bit of extra stuff like syntax-aware formatting and syntax highlighting. And maybe you need to run in a terminal, so the really popular editors like Visual Studio Code won’t work. But you're not going to be doing automated refactors, or doing lots of repetitive edits that are almost-but-not-quite the same, or making similar changes across multiple files...

In this case, I actually *don't* recommend Emacs unless you're already using it for another reason! Even with `cua-mode`, Emacs' keybindings are too much to learn for something this simple. I actually recommend `micro` for this purpose.

Micro editor (WWW)

Fancy text editing

So, suppose you want to do those things I just said you didn't want to do? My cow-orkers are always mystified that I can do this kind of thing when they watch over my shoulder while I edit. In the popular modern text editors (Sublime, VS Code), you'd use multiple cursors for this kind of thing. In Emacs, you have several choices of how to do this — multiple cursors, keyboard macros, or `iedit-mode`.

I do kind of recommend Emacs if you do this kind of thing on anything like a regular basis, but it's certainly doable with the popular graphical editors.

IDE-like programming language editing

There was a time, long ago, when what you might call IDE-dependent languages like Java were new, when Emacs was *not* a good choice for this kind of usage. The only languages Emacs had good completion and navigation support for were Emacs Lisp and Common Lisp; nobody used code completion with C, and C navigation with TAGS was considered sufficient. Emacs made progress in this area over the years, but it was always piecemeal, language-by-language, and for the languages where you really needed an IDE, always a step behind.

Today the situation is quite different. Emacs still has just as good support for the languages where it was traditionally strong, but now there are LSP (language server protocol) servers for many languages, and a general LSP adapter for Emacs. As a result, IDE-like features in Emacs are basically the same as in VS Code. It comes down to your choice, here.

Using programs that are part of or for Emacs

This is where things really start to get differentiated. There are lots of people who got into Emacs because they wanted to use `org-mode`, or `magit`, because there's really nothing out there in those classes of application that is as good. Once you start using programs that are written for Emacs, then not only do you have a reason to use Emacs to use those programs, but you start to have more incentive to use Emacs for all the other things you can use it for, and to get really familiar with its basics. At this point, you really should start leaning in...

Using Emacs as a completely integrated user interface

Here's the real payoff. Emacs is extremely internally consistent, even if some major modes (i.e., programs) written for it have their own quirks. Core keybindings work basicaly everywhere. Everything is discoverable (all interactive commands are reachable through M-x, every function interactive or not is searchable on F1-f, every variable no matter how internal is searchable on F1-v, etc.). Everything is extendable, and this includes program internals. The more time you spend in Emacs, and the less you do outside of it, the bigger the payoff.

Reducing the need for memorization

Over time, the things you use often will get ground into your muscle memory. Emily reports that when she doesn't use Emacs for a while, she forgets memorized commands and shortcuts. I suppose I do too, but I don't actually notice this anymore, because I have coping mechanisms, some of which I'll share here:

Use a command-completion framework

There are a very wide variety of command (and other) completion frameworks for Emacs, as people have been trying to perfect them for their own use since around 2005. The default completion framework is a little helpful (type M-x, the beginning of a command, and hit tab to get a list of commands that start with that prefix), but it doesn't do fuzzy matching, or, indeed, matching starting from the middle of a command. The included package `ido-mode` greatly improves the default behavior without being very intrusive, but we can go farther. Lots of starter-kit type distributions for Emacs use `helm`, which is very full-featured. I find it a bit slow and intrusive, myself. Another popular choice is `ivy`, often used with `swiper` for searching and `counsel` to provide ivy-flavored versions of common commands. It's pretty good, but I prefer `selectrum` and `consult`, which provide the same things, but are more broadly compatible with Emacs' built-in completion mechanisms. I should share my own configuration at some point; it's too verbose to include in this note.

Use which-key

Which key extends Emacs' built-in display of partially typed keybindings to show a list of all the possible follow-ups to a prefix key. This is really helpful for learning minor modes, since their keybindings are often on C-c <some-char> <some-other-char>. It can be a little slow, but I didn't really notice it during the Old Computer Challenge.