diff --git a/docs/getting_started.org b/docs/getting_started.org
index 90669c4bc..828ffdb14 100644
--- a/docs/getting_started.org
+++ b/docs/getting_started.org
@@ -50,7 +50,7 @@ us know!
     - [[#installing-packages-from-external-sources][Installing packages from external sources]]
     - [[#pinning-packages-to-specific-commits][Pinning packages to specific commits]]
     - [[#disabling-packages][Disabling packages]]
-    - [[#changing-a-recipe-for-a-included-package][Changing a recipe for a included package]]
+    - [[#changing-a-recipe-for-an-included-package][Changing a recipe for an included package]]
     - [[#usingloading-local-packages][Using/loading local packages]]
   - [[#configuring-doom][Configuring Doom]]
     - [[#configuring-packages][Configuring packages]]
@@ -886,7 +886,7 @@ packages:
 ensure your changes take effect.
 #+end_quote
 
-*** Changing a recipe for a included package
+*** Changing a recipe for an included package
 If a Doom module installs package X from one place, but you'd like to install it
 from another (say, a superior fork), add a ~package!~ declaration for it in your
 =DOOMDIR/packages.el=. Your private declarations always have precedence over
@@ -1176,7 +1176,7 @@ Placing this on top of a lisp form will do one of two things:
    =~/.emacs.d/.local/autoloads.el=, which is read very early in the startup
    process).
 2. Or copy that lisp form to Doom's autoload file verbatim (usually the case for
-   anything other then ~def*~ forms, like ~defun~ or ~defmacro~).
+   anything other than ~def*~ forms, like ~defun~ or ~defmacro~).
 
 Doom's autoload file is generated by scanning these files when you execute ~doom
 sync~.
@@ -1414,9 +1414,9 @@ org module documentation]] for details on how to add support for it.
 #+END_SRC
 
 These two lines are a common sight in Emacs configs, but they are unnecessary
-for Doom Emacs. We already use the more sophisticated =wsbutler= to manage
+for Doom Emacs. We already use the more sophisticated =ws-butler= to manage
 extraneous whitespace. However, you might have the impression that it isn't
-working. That's because =wsbutler= works in two unusual ways, meant to be less
+working. That's because =ws-butler= works in two unusual ways, meant to be less
 imposing than its alternatives:
 
 1. It only cleans up trailing whitespace /on lines that you've touched/ (but
@@ -1431,7 +1431,7 @@ imposing than its alternatives:
    However, if it's truly deliberate, ~M-x delete-trailing-whitespaces~ and ~M-x
    whitespace-cleanup~ are available to be called =deliberately=, instead.
 
-2. =wsbutler= replaces trailing whitespace and newlines with *virtual*
+2. =ws-butler= replaces trailing whitespace and newlines with *virtual*
    whitespace. This is whitespace that only exists in the Emacs buffer, but
    isn't actually written to the file.
 
@@ -1470,7 +1470,7 @@ provide tools to make this easier. Here are a few things you can try, first:
   issues that originate from upstream.
 
 + If you happen to know what module(s) are relevant to your issue, check their
-  documentation (press =<leader> h m= to jump to a module's documentation). Your
+  documentation (press =<leader> h d m= to jump to a module's documentation). Your
   issue may be documented.
 
 + If possible, see if the issue can be reproduced in vanilla Emacs (Emacs
@@ -1559,9 +1559,9 @@ and before the subcommand. This will be fixed eventually.
 Often, you may find it helpful for debugging to evaluate some Emacs Lisp. Here
 are couple things you can do:
 
-+ Use =M-;= (bound to ~eval-expression~),
++ Use =M-:= (bound to ~eval-expression~),
 + =SPC x= will open a scratch buffer. ~M-x emacs-lisp-mode~ will change it to
-  the appropriate major mode, then use ~+eval:region~ (=gr=) and ~+eval:buffer~
+  the appropriate major mode, then use ~+eval:region~ (=gr=) and ~+eval/buffer~
   (=gR=) to evaluate code,
 
 ** How to determine the origin of a bug
@@ -1571,7 +1571,7 @@ in a fresh instance of Emacs with varying amounts of Doom loaded (none at all,
 all of it, or somewhere in between). This can be helpful for isolating bugs to
 determine who you should report a bug to.
 
-If you can recreate a bug in vanilla Emacs than it should be reported to the
+If you can recreate a bug in vanilla Emacs then it should be reported to the
 developers of the relevant packages or, perhaps, the Emacs devs themselves.
 
 Otherwise, it is best to bring it up on the Doom Emacs issue list, rather than