On Learning Emacs

Published: 2020-11-13

Classical learning curves for some common editors

I once came across a Tweet telling people how to use Emacs like this: step 1, download Emacs; step 2, spend the next 10 years configuring it. At first, this seems pretty silly, yet, there are some truths in it. I, for one, didn’t spend 10 years before becoming comfortable using Emacs as my daily driving horse in software development. However, I could very well imagine that after 10 years I’d still be tinkering my Emacs config with a sense of satisfaction.

In retrospect, I found it amusing that both of my two favorite tools in software development, i.e. Clojure and Emacs, don’t seem to care much about the friendliness for newcomers. Yes, the community is very welcoming. However, the tools themselves are pretty demanding for the newcomers. Clojure required a huge leap of faith to unlearn most of my previous OOP experiences, whereas Emacs required me to design my own text editor from scratch and to have some understanding of the ELisp programming language. Neither of them promise newcomers to “hit the ground running” or “learn it over the weekend”.

In my observation, the whole software industry puts too much spotlight on “the latest and the greatest” things. FOMO, the fear of missing out, has fueled a culture of desiring speed. The easiness of learning has become an advertising term for many of the software tools such as libraries and languages. However, the effectiveness of a tool would eventually outweigh the difficulty to learn it in the long run. If I saved myself 15 minutes for using Emacs every day at work, I already saved myself 65 hours last year. That is almost three extra days an year. Even if I initially had spent a full week do nothing but learning Emacs, I would still start seeing the payoffs in the third year, as well as the rest of my life. The math isn’t really important here. To be honest with you, I don’t think I merely saved 15 minutes a day for using Emacs. The important thing is this - the ROI of learning a new tool is a long game. The longer you stick with it, the less significant the initial investment is. What’s more important is the capability of the tool itself.

That brings me to the next key point: Emacs isn’t just a text editor. Some people think Emacs as their operating system. I like to think Emacs as an integrated development environment. Modern software development usually involves multiple tools: text editor, compiler, interpreter, repl, test runner, version control system, database client, or the browser. Every project is different and there is no one single IDE will meet all needs. We reach different tools for different purposes and inevitably are forced to make context switches. Context switches break our development flow. It’s draining for me to constantly reaching for a different tool with different key bindings or requires me to use the mouse. I really would prefer to stay inside one tool with the same universal key bindings all the time.

When I started off learning Emacs, I tried to find the best and most conventional way to set it up. I was also feeling wrong for using the Vim key bindings rather than the default Emacs key bindings. This idea seems silly to me now for there should be no one true way of using Emacs. Every one is using Emacs differently, with different background, under different context. I use a different keyboard than most people I know. I have a Planck keyboard that only has 50 keys. A lot of the special characters I cannot type without a modifier key already. I couldn’t afford to hit a key chord that requires hitting multiple modifier keys plus a special character. Something like C-M-$ would be pretty humanly impossible to press with one hand. I’m glad Emacs is flexible enough to fit my needs.

To recap, here’s my key points: 1. The effectiveness of a tool would eventually outweigh the difficulty to learn it in the long run. 1. Emacs is an integrated development environment rather than a text editor. 1. There’s no one true way of using Emacs.