Want to see the full-length video right now for free?Sign In with GitHub for Free Access
Glass TTYs replaced paper printouts in the mid-1970s. That change precipitated a fertile era for screen editor development. Software engineers explored lots of paradigms for editing text, but only two models are still around: Emacs and vi.
While vi(m) follows the Unix convention of doing "one thing well" (that is, just editing text), Emacs emphasizes extensibility and deep integration with the rest of the system.
It achieves that by being, at its core, a Lisp interpreter. Almost all of its editing functionality is written in its own Lisp dialect, Emacs Lisp. Hitting a key is exactly equivalent to evaluating a function. Since the whole editor is written in Emacs Lisp, which users and package creators can also write, there's no distinction between built-in functions and user-written extensions. This allows for some pretty impressive behavior.
We're big Vim fans here at Upcase, so before we discuss Emacs-specific capabilities, let's talk about Vim emulation. A lot of editors have some kind of Vim emulation mode; it usually binds "j" and "k" and a handful of other keys, but often fails at composing expressions and defining new text objects, which are really our favorite parts.
Emacs has evil, the Extensible VI Layer. Evil is an extremely featureful Vim emulator. It supports virtually all the functionality of Vim and allows users to add functionality by writing plain old Emacs Lisp. Since there's no distinction between built-in text objects and user-created ones, users and package maintainers can easily create their own.
evil-mode doesn't include a Vimscript interpreter (yet?), users have
ported many popular Vim packages over to Emacs, like
There are several tools for doing fuzzy searching of lists.
ido is one popular
helm is another). Both of these are external packages that don't come
with Emacs by default, so they have to be installed through the built-in package
manager (which is included in Emacs 24+).
We can use
ido to fuzzy-search through lists of files, functions, or strings.
For example, if we've got
ido configured, opening up a file with
will trigger a fuzzy search for opening files. While Vim has its own
collection of fuzzy selection plugins (CtrlP, CommandT, and Unite), you'll
be hard pressed to integrate the as deeply into your workflows as with Emacs
thanks to its focus on extensibility.
Buffers in Emacs don't have to be tied to files. They can be used for anything,
including the output of commands. For example, when we recursively search
through our files with
M-x rgrep we can find a list of files that contain a
given expression. The buffer that
rgrep generates contains a list of links to
lines in files, each of which contains the search term. We can follow these
This buffer can do more than just display links, though. By hitting
C-x C-q we
can make the buffer editable, which allows us to modify every line right there
in the list of results. If we want to rename all those terms we can use
do a search and replace, and then hit
C-c C-c to save the changes.
Magit is a terrific Emacs package that provides a built-in interface to git.
It's an external package, so you'll need to install it before you can use it.
It's got tons of functionality, so we can't investigate it in too much detail
here, but by running
M-x magit in a git-managed project you can open up its
interface and start trying it out. You can view a file's changes by hitting
Tab to expand them, stage and commit changes, and browse an interactive log
Emacs can browse and manage files graphically through the
dired (or "directory
editor") mode. If we open a directory with
C-x C-f we'll see a list of the
files it contains. We can navigate with the arrow keys, and open files and
Enter. We can even do nifty stuff like renaming files with
R and creating directories with
We can also use
dired for bulk file renaming (much like how we used
We can hit
C-x C-q to make the buffer writable, modify all the files as we'd
like, and hit
C-c C-c to save the changes. This is usually easier than writing
a shell script and dramatically better than renaming files manually.
Emacs has a built-in dynamic help system.
Most of the help system's commands start with
C-h. You can look up the
documentation on a function with
C-h f, a description of the current mode with
C-h m, and investigate a keybinding with
C-h k. You can access the help
system's documentation itself with
Most Emacs functions include docstrings, which document the behavior of the function. The buffers that the help system displays are dynamically generated, and they often make use of docstrings.
C-h f next-line, for example, looks up the documentation for the
next-line function. The documentation buffer displays the function's
docstring, describes how to call the function, and (assuming you haven't removed
the binding) notes that it's currently bound to
It also includes a link to the code defining the function, which you can follow and inspect.
Generating the documentation buffers dynamically is extremely helpful. It means that:
C-h m pops open a buffer containing documentation on the current mode.
Every buffer has exactly one major mode (which when programming is generally the
mode associated with the language you're writing, like
ruby-mode) and zero or
more minor modes (things like
rspec-mode to run tests from within Emacs, or
global-hl-line-mode to always subtly highlight the current line).
Some minor modes might be specific to a certain buffer (you might only want to
rspec-mode in a certain file), and others might be global (if you like vim
keybindings you might always want to enable
Emacs can be thought of as a Lisp REPL that just happens to load some good libraries for editing text.
If we open a new buffer and put it in
M-x emacs-lisp-mode, we can evaluate
expressions from within the buffer. For example, we could write:
(+ 1 2 3)
If we place the cursor (technically called "point") after that expression and
C-x C-e, Emacs will evaluate that expression and print the result in the
"minibuffer" at the bottom of the screen. Hopefully we'll get
Learning Emacs is a big undertaking, and it might take a month or two to reach a reasonably level of proficiency. Persevere! Emacs has been actively developed for forty years, and it's very likely going to last another forty. The time you spend learning it now will pay immense dividends over the coming decades---there aren't many tools that you can expect to use for the entirety of your software career.
If you're on a Mac, don't bother with the pre-installed Emacs that comes with OS X; it's tragically out of date. Instead, we'd recommend getting the latest Cocoa build.
To start learning, the built-in tutorial (accessible through
C-h t) is
sufficient, but you'll probably want to keep a quick reference on hand.
Sacha Chua created a
very good cheatsheet. Remember to move past the first step eventually.
Harry picked up a Emacs reference mug from the FSF when he started learning Emacs. This has the dual benefit of helping you reference common commands while causing your co-workers to roll their eyes (which he enjoys).
There are a number of great starter kits out there, like Prelude and Spacemacs, which come with all the bells and whistles preinstalled. We don't really recommend them when you're first getting started, though, since they you probably don't need everything they provide, and you may find that they obfuscate what's really going on. Harry recommends his own collection of starter defaults, sensible-defaults.el, since it's just a collection of small functions that perform some common tasks (like enabling syntax highlighting everywhere).
There are a ton of other resources out there for folks getting started in Emacs:
#emacsIRC channel on Freenode is extremely knowledgeable and friendly.
.emacs.ddirectories on Github, so it's often worth scrounging through them for neat tricks. Here's Harry's, for example.