Updated 2022-09.

While Visual Studio Code may be the de-facto kind of the text editor world among programmers, the neckbeard tools of vim and Emacs aren’t unheard of.

Here are my notes related to “why I use Emacs”.

My Background

I started using Emacs because of its org-mode feature.

Before using emacs, I mainly used vim (and would aim enable vim keybindings in whatever tool I could). Even in Emacs, I do prefer vim’s modal editing.

Emacs and Vim Both Allow Keyboard-Driven Text Navigation/Manipulation

Emacs and vim are mostly driven using the keyboard.
The big benefit of being keyboard driven is not having to move your hand to move the mouse.
The downside to this there’s a steeper learning curve to learning the key bindings in either editor.

Or I’d summarise it like this:

VSCode Vim Emacs
Ease of use, coming from Notepad Easy Hard Hard
Learning Curve Do people learn VS Code? Hard Hard
Out of the box experience Usable Adequate Abysmal
Prefers GUI or terminal? GUI-only Prefers terminal Prefers GUI
Text Navigation with Keyboard No frills Expressively Modal Uses modifier keys
Extending Like writing an App with the terrible VimL comprehensive, with Lisp

Emacs and vim take different approaches to keyboard input:

Vim being ‘modal’ means keyboard input behaves differently depending on what ‘mode’ it’s in.
Vim has an ‘insert’ mode, where it behaves like common text editors.
In Vim’s ‘normal’ mode, though, the keys are used to navigate around and to maniputale text.
e.g. the letters hjkl are used for cursor navigation.
This manipulation tends to involve action + motion. The example I like is ci". Where c indicates “change”, i" indicates the motion “text inside ""”. e.g. with the cursor in printf("hello world"), inputting ci" is the same as selecting hello world and deleting it.

Emacs’ approach to “driven by the keyboard” is to use modifier keys like “Ctrl” (C-) and “Alt” (M-).
e.g. C-f/C-b move forward/backward one letter at a time, whereas M-f/M-b more forward/backward one word at a time. C-a/C-e move to the start/end of a line, whereas M-a/M-e move sentences at a time.

The use of modifier keys is sane enough that macOS input adopts many of the Emacs-style bindings. (e.g. “C-a” will move to the beginning of the line, “C-e” moves to the end).

So, while vim’s keybindings don’t resemble Emacs’ in the slightest, in a broad sense they’re similar in the sense that you don’t have to reach for the mouse to for navigations fancier than cursor keys + Home/End + PageUp/PageDown.
– Despite how crap the out of the box experience is, and that it’s got a steep learning curve, I would still absolutely recommend a programmer who cares about mastering their tools learn Vim keybindings.

The Doom Emacs Distribution is Great

I still think it’s something of a rite-of-passage to having a go at trying to configure an Emacs (or Vim) into something usable; especially for students who have the spare time to follow community guides and recommendations.

That could be thanks to the little yak-shaver in me that constantly wonders if there’s a more streamlined way to complete some task.

But, I gotta say. The doom emacs distribution has won me over.

It brings with it a good set of quality packages which enhance everyday code editing, as well as a well thought out set of keybindings for invoking these. (e.g. running npm run X is <SPC> m n r. Rather, <SPC> m is the prefix to all key sequences related to the local _m_ode. And then n r being to bring up node run isn’t too difficult to remember).

Great Things About Emacs (Hard to Find Elsewhere)

Org Mode

Org-mode is a markup format, with a long tail of features for organising: taking notes and managing tasks.

  • Not without its limitations and downsides. But.
    org mode deserves its reputation as an excellent tool for organising things in plain text.
  • What I love about org-mode:
    • An org mode file is a bunch of headings and sub-headings. The headings can be collapsed/expanded (like code-folding in other editors).
    • The headings can have meta-data like key-value properties, tags, a “TODO” state, etc..
    • All of which is nice for writing notes in org-mode.
      But a great aspect of this is org-mode’s “agenda” feature. Org agenda provides ways to search through and display org headings. (It’s an “agenda” because dates can be attached to headings, so this can serve as an “agenda”).
      • This might sound underwhelming, but it allows you to structure your tasks and notes in org documents in a way which suits you, and to be able to quickly find what you need to see.
      • I’ve heard WorkFlowy is an example of software which aims for this expressiveness, with the trade-off of being simpler to use than org-mode.
        But as far as I can tell, the default go-to note taking, task management and calendar tools people use aren’t as flexible.
  • For what it’s worth, Org mode has various other features I haven’t made use of. e.g. it has support for exporting org files into other formats, it has great table editing features, it can be used to track time (by clocking in and out of headlines).


Maybe you’ve been fooled to think that programmers who know git would use git on the command line, and wouldn’t need to use a GUI.

Magit, however, is an excellent interface on top of git, that makes using the command line feel archaic.

  • You can find GUIs for git embedded in environments like vim, Visual Studio Code or any IDE.
    But, Magit is an excellent package. It’s good enough to be worth using emacs for, even if you don’t use any other part of it.
  • To be fair, git can still a tough beast to use.
  • Magit seems to be a “best of both worlds” situation:
    • Power users are at there best when they can stick to their keyboard to get the job done.
    • New users need the discoverability that comes along with something like a GUI or dropdown menu.
    • Magit’s excellent Developer Experience (DX) caters to both of these. Power-Users can quickly input the sequences they know they need
      • Some of my favourites:
        • c c to commit,
        • P -f p to push --force-with-lease,
        • r -a i to rebase --autosquash,
        • c F to instantly amend an old commit with some changes which weren’t checked in.


Emacs’ great discoverability eases out much of the difficulty that comes from it being able to do so many things.

  • which-key is fantastic, especially in tandem with Emacs style of executing commands via key sequences.
  • magit’s user interface
    • magit itself is great; but imo vim’s git plugin is pretty neat too.
  • the describe-* help commands.
    • e.g. C-h w binds to “where-is”, which lists keybindings to a command.
    • C-h c binds to describe-key-briefly, which shows the command for a key sequence
    • C-h k binds to describe-key, which opens the documentation for a command.
    • C-h b binds to describe-bindings, describe mode are also really good for listing the currently available bindings.
      • helm and ivy/counsel have descbinds makes this really convenient.


  • I know that most programs have plugins/extensions.
    But it seems that the approach Emacs takes (with a heavy emphasis on “commands”) allows for extending the program that’s hard to find elsewhere.
  • “Everything is a command”, seems like a huge win in the interactions with the editors it allows.
    Especially since with the commands in Elisp, you can:
    • look at the source code
    • find the documentation documentation
    • run by typing out the command name
    • bind to keybindings

Useful Guides

Sacha Chua’s Visual Guide

This is very cute, utterly fantastic.
She also links to some Emacs Beginner Resources.

Tuhdo’s Emacs Tutor

tuhdo’s emacs-tutor comes with large, pretty gifs of Emacs doing its thing.
I kindof like that it shows off feature based stuff at the start.

Somewhat apprehensive at the thought of a community which needs fancy-animated-gifs to get excited about anything, though: – I’m not sure about Emacs, but Vim at least has excellent help documentation.

awesome-emacs is a pretty good starting point.