The Doom Emacs cheat sheet is written in org mode on purpose

An org mode document that GitHub cannot show properly

This is a cheat sheet for Doom Emacs, and the description says plainly that it is mostly from the guides the author sees online. The repository holds three files, README.org as the main document, plus GolangInDoom.org and PythonInDoom.org with additional instructions for those two languages. The format is the first design decision, and the author explains it directly. GitHub does not render org files very well, so it is best that you clone the repository and open it in Emacs. That choice makes sense for the audience. Org mode in Emacs gives you folding, links between headings, and the ability to edit the notes while you read them, and a document meant to be lived in rather than skimmed is better served by the tool the notes are about. The consequence for anyone browsing the repository on the web is that they see raw markup, which is a reasonable trade for the people the document is written for. The licence field in the repository metadata is empty and the README does not name one, and the primary language is not detected, which is consistent with a personal notes repository rather than a published project.

The built-in help is the real answer to what a binding does

The opening advice is the most useful thing in the document, and it is not about a binding at all. Use Doom Emacs's built-in helps to understand how things work under the hood and change them to suit your needs, and the sheet then lists the four help commands to do it:

- =SPC h k= tells you how key combinations translate to Emacs commands.
- =SPC h w= helps you find keyboard shortcuts for different commands.
- =SPC h v= lets you see what's inside variables and change them.
- =SPC h f= tells you about functions and where they are defined.

A fifth entry, SPC h b b, lists all keybindings. That is the author's position stated as a workflow. Rather than memorising a table, you learn how to look up the table, which is the difference between using a distribution and being able to change it. The sheet also supplies the command abbreviations used throughout, with C for Control, M for Alt or Option, S for Super or Command and SPC for the Space key, and it uses a compact org mode notation where a binding is written inside equals signs. The general commands that follow are deliberately minimal, with SPC f s to save the current file, SPC : to enter a command, SPC q q to close Emacs and SPC f D to delete the current file, which is the kind of starting set a new user needs and nothing more.

Projectile and Dired cover the file system side

The file system part of the sheet is where a new user spends the most time, and it covers two areas. Projectile handles projects, with SPC p p to open a project, SPC SPC to open a file in a project, SPC o p to open the file explorer, SPC f r for recently visited files, SPC p r for recently visited files in a project, and two M-x commands that discover projects in a given directory or in the folder defined by the projectile-project-search-path variable. The shell is also wired in, with SPC o E opening eshell in fullscreen and SPC o e opening it in a popup window. Dired, the directory editor, gets its own section with the bindings in a block:

- Press =C-x d= to open dired.
- Use =RET= to go to a folder or open a file.
- Use =-= for going one folder back
- Use =+= for creating a new directory
- Use =d= to mark the files for deletion, press =x= to delete.

The rest of the Dired list covers marking with m and unmarking with u, inverting the selection, sorting by modes, changing permissions and owner, copying and moving within a window or to another window, editing a name, and the dired-do-what-i-mean-target setting. One line in the source deserves a flag, because the sheet lists t twice with two different meanings, once to invert the selection and once to switch between files and directories, which is exactly the kind of detail that only shows up when you read the original rather than a summary of it.

Buffers, windows and workspaces are three different things

The sheet separates concepts that newcomers routinely mix up. A buffer can be a terminal, a file or a directory, and the buffer commands are SPC b b to open another buffer, SPC b B to see all of them, SPC , to switch buffers, SPC SHIFT , to switch to all buffers, SPC b X for a scratch buffer and SPC b s to save and name it. A window is a pane on screen, and the window commands are:

- =SPC w v= window split vertically
- =SPC w s= window split horizontally
- =SPC w w= to switch windows
- =SPC w q= to close window, frame, quit EMACS if last frame

The rest of the window section covers enlarging the current window, undoing the last window change, balancing sizes, adjusting height and width, and moving a window with the vim motion key SPC w H. Workspaces are a third layer again:

- =SPC TAB n= New workspace
- =SPC TAB N= Newly named workspace
- =SPC TAB [= Previous workspace
- =SPC TAB ]= Next workspace

A workspace can be removed with SPC TAB d, the last session restored with SPC TAB R, and switched directly with M-1, M-2 and so on.

The package cycle in .doom.d and .doom.d/config.el

The sheet walks through installing a package using org-super-agenda as the worked example, and the sequence is the standard Doom cycle. Open the configuration with SPC f p, add the package to the .doom.d/package.el file, close and run doom refresh, then move to .doom.d/config.el to configure it. The configuration itself is done with the def-package! macro, and the sheet maps its keywords to their jobs, with :init used for setting the package up, :config to set configuration after the package has been initialised, and :after to set which package it should load after. It also mentions :after! for configuring packages that are already there. The lookup that makes those keywords usable is space h help, which shows the method man pages. For a new user this section is the most immediately actionable part of the whole document, because it turns the abstract idea of a package manager into five concrete steps with named files, and because the difference between :init, :config and :after is the kind of detail that takes an afternoon to work out from the source.

Evil-snipe is the jump navigation the sheet pushes hardest

The longest section of the document is about evil-snipe, and that emphasis tells you what the author finds valuable. Inline navigation starts with f followed by the letter you want to jump to, with t as the variant that moves the cursor to the character before what you searched for, v to enter visual mode so you can select text with v t or v f, and s to snipe. The sheet is precise about the history behaviour, noting that evil-snipe remembers your last search so the , and ; keys jump to the previous and next occurrence, and that F or T go backwards. For longer distances it moves to avy, with g s SPC and then the letter avy gives you, and the SPC h v entry is where you change the avy-all-windows variable so the search covers every open window. The examples are practical. Removing a word uses g s SPC select-one-letter x select-the-removal-spot, with X to stay in your original spot of search. Correcting a spelling uses g s space select-one-letter i select-the-correction-spot, and the sheet notes that ispell has to be installed on your system first. Yanking a word from one place to another follows the same pattern with y. The pattern is consistent enough that the sheet is effectively teaching one grammar of motion, and that is why it is the section worth reading even if you never open Dired.

Editorial conclusion

Adopt this cheat sheet if you have just started with Doom Emacs and want a worked example of how the pieces fit together, particularly for the package cycle and for jump navigation with evil-snipe. Do not treat it as reference documentation, because it is explicitly assembled from guides the author reads online, it is a personal workflow rather than a canonical key map, and it will drift from your Doom Emacs version as the distribution changes. Before you rely on it, check the bindings you copy against your own version with the built-in help, and if you want to understand Emacs rather than Doom Emacs, follow the author's advice and set up a minimal configuration yourself first.

Frequently asked questions

Official sources

1. Issues
2. niyumard/Doom-Emacs-Cheat-Sheet on GitHub
3. README