Learn Enough Text Editor to Be Dangerous
Michael Hartl
Contents
- About the author
- Chapter 1 Introduction to text editors
- Chapter 2 Modern text editors
- Chapter 3 Advanced text editing
About the author
Michael Hartl is the creator of the Ruby on Rails Tutorial, one of the leading introductions to web development, and is cofounder and principal author at Learn Enough. Previously, he was a physics instructor at the California Institute of Technology (Caltech), where he received a Lifetime Achievement Award for Excellence in Teaching. He is a graduate of Harvard College, has a Ph.D. in Physics from Caltech, and is an alumnus of the Y Combinator entrepreneur program.
Chapter 1 Introduction to text editors
Learn Enough Text Editor to Be Dangerous is designed to help you learn to use what is arguably the most important item in the aspiring computer magician’s bag of tricks: a text editor (Figure 1.1). Learning how to use a text editor is an essential component of technical sophistication.

Unlike other text editor tutorials, which are typically tied to a specific editor, this tutorial is designed to introduce the entire category of application—a category many people don’t even know exists. Moreover, editor-specific tutorials tend to be aimed at professional developers, and generally assume years of experience, but Learn Enough Text Editor to Be Dangerous doesn’t even assume you know what a “text editor” is. Its only prerequisite is a basic understanding of the Unix command line, such as that provided by Learn Enough Command Line to Be Dangerous.1
Because Learn Enough Text Editor to Be Dangerous is part of a series of tutorials designed to teach the fundamentals of software development (with a particular focus on the prerequisites for learning web development with the Ruby on Rails Tutorial), it’s ideally suited for anyone who wants to learn the skills necessary to work with developers or to become developers themselves. Finally, even if you already know how to use a text editor, following this tutorial (and doing the exercises) will help fill in any gaps in your knowledge, and you might even learn a few new tricks.
Unlike most programs used to produce written documents, such as word processors and email clients, a text editor is an application specifically designed to edit plain text (often called just “text” for short). Learning to use a text editor is important because text is ubiquitous in modern computing—it’s used for code, markup, configuration files, and many other things.2 (Indeed, I’m using plain text to write this very document.) Although it’s surprisingly difficult to define exactly what “plain text” is, from a practical perspective it means that the text itself doesn’t have any formatting, or at least none that matters. There’s no notion of emphasized or boldface text, the font size and typeface
don’t matter, etc.—the only thing that does matter is the content. For example, although the previous sentence contains formatted output like this, its source is plain text, and appears as in Listing 1.1.3
There's no notion of <em>emphasized</em> or <strong>boldface</strong> text,
the <small>font size</small> and <code>typeface</code> don't matter,
etc.—the only thing that does matter is the <em>content</em>.
In Listing 1.1, the desired formatting options are indicated with special tags (such as the HTML emphasis tag <em>…</em>
) rather than by changing the appearance of the text itself.4 This is the main reason why the more familiar word processor programs such as Word aren’t well-suited to editing plain text, and a different sort of tool is needed (Box 1.1).
Even if you’ve never used a text editor, the chances are good that you’ve used a similar tool, a word processor. There’s a lot of overlap between the features of word processors and text editors. For example, they both allow you to create documents, find and replace or cut/copy/paste text, and save the results. The main difference is that word processors are generally designed to produce documents following the principle of “What You See Is What You Get” (WYSIWYG, pronounced “WIZ-ee-wig”), so that effects such as emphasis or boldface are achieved directly in the application, instead of with plain-text markup like <em>emphasis</em>
or **boldface**
. For the most part, word processors also save their results in proprietary formats that sometimes go bad (as many who’ve tried opening old Word files have learned to their chagrin).
In contrast, text editors are designed to modify plain text, one of the most universal and durable formats. Text editors also differ from word processors in having features aimed at more technical users, including syntax highlighting for source code (Section 3.2.1), automatic indentation (Section 3.2.3), support for regular expressions (Section 3.4.3), and customization via packages and snippets (Section 3.5). A good text editor is thus an essential tool in every technical person’s toolkit.

Building on the material developed in Learn Enough Command Line to Be Dangerous, Learn Enough Text Editor to Be Dangerous starts by covering the important Vim editor (Section 1.1), which can be run at the command line directly inside a terminal window. Vim will give us a chance to see our first examples of the most important functions of a text editor, but because Vim can be forbiddingly complex for a beginner, in this tutorial we will cover only the bare minimum necessary to make basic edits. The rest of the tutorial will expand on the themes developed in Chapter 1 by describing some of the many powerful features required in any programmer-grade text editor, with examples drawn principally from Sublime Text, a freely available cross-platform editor,5 with concepts applicable to the closely related Atom6 and Visual Studio Code editors and to Cloud9, a cloud IDE.7
As with Learn Enough Command Line to Be Dangerous, this tutorial is part of the Unix tradition, which includes virtually every operating system you’ve ever heard of (macOS, iOS, Android, Linux, etc.) except Microsoft Windows. Although all the editors we’ll discuss do run under Windows, using a non-Unix OS introduces friction into the process, so Windows users are encouraged to set up a Linux-compatible development environment by following the Windows steps in Learn Enough Dev Environment to Be Dangerous or use a Linux-based cloud IDE (which is also covered in Learn Enough Dev Environment to Be Dangerous).
The focus throughout Learn Enough Text Editor to Be Dangerous is on general principles, so no matter which editor you end up using, you will have a good mental checklist of the kinds of tasks you should rely on your editor to perform. In addition, because the details vary by particular text editor and by system, this tutorial presents an ideal opportunity to continue developing your technical sophistication (Box 1.2). Finally, don’t feel any pressure to master everything at once. You can be productive with even a small subset of what’s included in this tutorial. Because technically sophisticated people use text editors practically every day, you’ll keep learning new tricks in perpetuity.
The phrase technical sophistication, mentioned before in Learn Enough Command Line to Be Dangerous, refers to the general ability to use computers and other technical things. This includes both existing knowledge (such as familiarity with text editors and the Unix command line) and the ability to acquire new knowledge, as illustrated in “Tech Support Cheat Sheet” from xkcd. Unlike “hard skills” like coding and version control, this latter aspect of technical sophistication is a “soft skill”—difficult to teach directly, but essential to develop if you want to work with computer programmers or to become a programmer yourself.
In the context of text editors, technical sophistication includes things like reading menu items to figure out what they do, using the Help menu to discover new commands, learning keyboard shortcuts by reading menu items or Googling around, etc. It also involves a tolerance for ambiguity: technically sophisticated readers won’t panic if a tutorial says to use ⌘Z to Undo something when it’s actually ⌃Z on their system. They also won’t panic if they see ⌘Z but don’t know what ⌘ means, because they know they can skim ahead to find something like Table 2.1, or simply Google for it. Perhaps the most important aspect of technical sophistication is an attitude—a confidence and can-do spirit in the face of confusion that is well worth cultivating.
Throughout the rest of Learn Enough Text Editor to Be Dangerous, we’ll refer back to this box whenever we encounter examples of issues that require a little technical sophistication to solve. With experience, you too will become one of the “computer people” from “Tech Support Cheat Sheet” who seem to have the magical ability to figure out technical things. (Warning: You might need a new shirt (Figure 1.3).)

1.1 Minimum Viable Vim
The vi (pronounced “vee-eye”) editor dates back to the earliest days of Unix, and Vim (pronounced “vim”) is an updated version that stands for “Vi IMproved”. Vim is absolutely a full-strength text editor, and many developers use it for their daily editing needs, but the barrier to Vim mastery is high, and it requires substantial customization and technical sophistication (Box 1.2) to reach its full potential. Vim also has a large and often obscure set of commands, which rarely correspond to native keybindings (keyboard shortcuts), making Vim challenging to learn and remember. As a result, I generally recommend beginners learn a “modern” editor (Chapter 2) for everyday use. Nevertheless, I consider a minimal proficiency with Vim to be essential, simply because Vim is utterly ubiquitous—it’s present on virtually every Unix-like system in the known universe, which means that if you ssh into some random server halfway ’round the globe, Vim will probably be there.
This chapter includes only Minimum Viable Vim—just enough to use Vim to do things like edit small configuration files or Git commits.8 It’s not even really enough to be dangerous.
But it’s worth noting that even mastering Minimum Viable Vim puts you in elite company—because Vim is so difficult, even a little Vim knowledge is the sort of thing that can impress your friends (or a job interviewer).
Note: If you’re using macOS, you should follow the instructions in Box 1.3 at this time.
If you’re using macOS, at this point you should make sure you’re using the right shell program for this tutorial. The default shell as of macOS Catalina is Z shell (Zsh), but to get results consistent with this tutorial you should switch to the shell known as Bash.
The first step is to determine which shell your system is running, which you can do using the echo
command:
$ echo $SHELL /bin/bash
This prints out the $SHELL
environment variable. If you see the result shown above, indicating that you’re already using Bash, you’re done and can proceed with the rest of the tutorial. (In rare cases, $SHELL
may differ from the current shell, but the procedure below will still correctly change from one shell to another.) For more information, including how to switch to and use Z shell with this tutorial, see the Learn Enough blog post “Using Z Shell on Macs with the Learn Enough Tutorials”.
The other possible result of echo
is this:
$ echo $SHELL /bin/zsh
If that’s the result you get, you should use the chsh
(“change shell”) command as follows:
$ chsh -s /bin/bash
You’ll almost certainly be prompted to type your system password at this point, which you should do. Then completely exit your shell program using Command-Q and relaunch it.
You can confirm that the change succeeded using echo
:
$ echo $SHELL /bin/bash
At this point, you will probably start seeing the following alert, which you should ignore:
The default interactive shell is now zsh. To update your account to use zsh, please run `chsh -s /bin/zsh`. For more details, please visit https://support.apple.com/kb/HT208050. [~]$
Note that the procedure above is entirely reversible, so there is no need to be concerned about damaging your system. See “Using Z Shell on Macs with the Learn Enough Tutorials” for more information.
1.2 Starting Vim
Unlike most of the modern editors discussed starting in Chapter 2, Vim can be run directly inside a terminal window, and requires no graphical interface.9 All you do is type vim
at the prompt:
$ vim
Typical results of running the vim
command appear in Listing 1.2 and Figure 1.4. In both cases, the tildes (~) are not characters in the file but rather represent lines that have yet to be defined.
~
~
~
~
~
~ VIM - Vi IMproved
~
~ version 7.3
~ by Bram Moolenaar et al.
~ Vim is open source and freely distributable
~
~ Help poor children in Uganda!
~ type :help iccf<Enter> for information
~
~ type :q<Enter> to exit
~ type :help<Enter> or <F1> for on-line help
~ type :help version7<Enter> for version info

If starting Vim is easy, learning to use it, at least at first, can be incredibly hard. This is mostly due to Vim being a modal editor, which is probably unlike anything you have used before (Box 1.4). Vim has two principal modes, known as normal mode and insertion mode. Normal mode is for doing things like moving around the file, deleting content, or finding and replacing text, whereas insertion mode is for inserting text.
When I first started to learn programming in the Unix tradition (as opposed to my childhood experience with Microsoft DOS, BASIC, and Pascal), I distinctly recall being absolutely mortified at the unbelievably primitive editor I was expected to use. At the time, I was a first-year undergraduate at Harvard University, working in a research group at the Harvard-Smithsonian Center for Astrophysics. The tool I had been handed was vi. To say that it seemed like a downgrade from word processors is a gross understatement (Figure 1.2).
What shocked me most about vi was modal editing: unlike word processors, vi didn’t let me just click in the window and start typing. Instead, there were a profusion of options (i
, a
, and o
among them) for switching to insertion mode, and all it took was a few wrong keystrokes for all hell to break loose. Although the intervening years have seen a proliferation of more modern text editors, whose design is much more like the click-and-type interface I expected from my experience with word processors, the enduring popularity of vi (via Vim) means that learning the basics of modal editing is a valuable skill, even if it might at first seem ridiculously foreign.
Going back and forth between these two modes can cause a lot of confusion, especially since virtually all other programs that edit text (including word processors, email clients, and most text editors) have only insertion mode. Part of what makes Vim particularly confusing is that it starts in normal mode, which means that, if you try entering text immediately after starting Vim (as in Listing 1.2), the result will be chaos.
Because confusion is the likeliest result if you’re not used to Vim’s modal editing, we’re going to start our study of Vim with the Most Important Vim Command™. One of my college friends, who was a huge partisan of vi’s (and hence Vim’s) historical rival Emacs (Box 1.5), claimed the Most Important Vim Command™ was the only one he ever wanted to learn. Here it is:
ESC:q!<return>
This command means “Press the Escape key, then type ‘colon q exclamation-point’, then press the return key.” We’ll learn in a moment what this does and why, but for now we’ll start by practicing it a couple of times in the exercises.
The Jargon File defines holy wars as follows:
holy wars: n.
[from Usenet, but may predate it; common] flame wars over religious issues. The paper by Danny Cohen that popularized the terms big-endian and little-endian in connection with the LSB-first/MSB-first controversy was entitled On Holy Wars and a Plea for Peace.
Great holy wars of the past have included ITS vs. Unix, Unix vs. VMS, BSD Unix vs. System V, C vs. Pascal, C vs. FORTRAN, etc. In the year 2003, popular favorites of the day are KDE vs. GNOME, vim vs. elvis, Linux vs. [Free|Net|Open]BSD. Hardy perennials include EMACS vs. vi, my personal computer vs. everyone else’s personal computer, ad nauseam. The characteristic that distinguishes holy wars from normal technical disputes is that in a holy war most of the participants spend their time trying to pass off personal value choices and cultural attachments as objective technical evaluations. This happens precisely because in a true holy war, the actual substantive differences between the sides are relatively minor. See also theology.
As noted in the Jargon File entry, one of the longest-raging holy wars is fought between proponents of vi and its arch-rival Emacs (sometimes written “EMACS”), both of which have played important roles in the Unix computing tradition. Both also retain much popular support, although my guess is that, with the popularity of Vim, vi has taken a decisive lead in recent years. Of course, this is just the sort of statement that serves to perpetuate a holy war—likely prompting Emacs partisans to, say, make claims about the superior power and customizability of their favorite editor.
If you wanted to start a new holy war, you might try something like, “Happily, the vi vs. Emacs holy war is now mostly a historical curiosity, as anyone who’s anyone has switched to a modern editor like Atom or Sublime.” It’s going to be quite a show—better bring some popcorn (Figure 1.5).

1.2.1 Exercises
- Start Vim in a terminal, then run the Most Important Vim Command™.
- Restart Vim in a terminal. Before typing anything else, type the string “This is a Vim document.” What happened? Confusing, right?
- Use the Most Important Vim Command™ to recover from the previous exercise and return to the normal command-line prompt.
1.3 Editing small files
Now that we know the Most Important Vim Command™, we’ll start learning how to use Vim for real by opening and editing a small file. In Section 1.2, we started by running vim
by itself, but it’s more common to use a filename as an argument. Let’s navigate to the home directory of our system and then run such a command, which will either open the corresponding file (if it exists) or create it (if it doesn’t):10
$ cd
$ vim .bashrc
Here .bashrc
is a standard configuration file for Bash.11
As noted above, the vim .bashrc
command will automatically create the corresponding .bashrc
file if it doesn’t already exist on your system. This important file is used to configure the shell, which is the program that supplies a command line—in this case, Bash, which is a pseudo-acronym that stands for Bourne Again SHell (also written as “Bourne-again shell”).12 (Recall from Box 1.3 that the default on macOS is now Zsh, so if you’re on a Mac you should follow the instructions there to switch to Bash if you haven’t already.)
As is common on Unix-based systems, the configuration file for Bash begins with a dot, indicating (as noted in Learn Enough Command Line to Be Dangerous) that the file is hidden. That is, it doesn’t show up by default when listing directory contents with ls
, or even when viewing the directory using a graphical file browser.
We’ll learn in Section 1.4 how to save changes to this file, but for now we’re just going to add some dummy content so that we can practice moving around. In Section 1.2, we learned that Vim starts in normal mode, which means that we can change location, delete text, etc. Let’s go into insertion mode to add some content. The first step is to press the i
key to insert text. Then, type a few lines (separated by returns), as shown in Listing 1.3.13 (There may be other existing content, which you should simply ignore.)
i
to insert. ~/.bashrc
1lorem ipsum
2dolor sit amet
3foo bar baz
4I've made this longer than usual because I haven't had time to make it shorter.
After entering the text in Listing 1.3, press ESC
(the escape key) to switch from insertion mode back to normal mode.
Now that we have some text on a few lines, we can learn some commands for moving around small files. (We’ll cover some commands for navigating large files in Section 1.6.) The easiest way to move around is to use the arrow keys—up, down, left, right—which is what I recommend.14 Vim has literally jillions of ways of moving around, and if you decide to use Vim as your primary text editor I recommend learning them, but for our purposes the arrow keys are fine. The only two additional commands I feel are essential are the ones to move to the beginning and end of the line, which are 0
and $
, respectively.15
1.3.1 Exercises
- Use the arrow keys to navigate to Line 4 in the file from Listing 1.3.
- Use the arrow keys to go to the end and then the beginning of Line 4. Cumbersome, eh?
- Go to the beginning of Line 4 by using the command mentioned in the text.
- Go to the end of Line 4 using the command mentioned in the text.
1.4 Saving and quitting files
Having learned a little about moving around and inserting text, now we’re going to learn how to save a file. Our specific example will involve making a useful new Bash command, but first we have to deal with the current state of the Bash profile file. The text we added in Listing 1.3 is gibberish (at least from Bash’s perspective), so what we’d like to do is quit the file without saving any changes. For historical reasons, some Vim commands (especially those having to do with file manipulation) start with a colon :
, and the normal way to quit a file is with :q<return>
, but that only works when there are no changes to save. In the present case, we get the error message “No write since last change (add ! to override)”, as shown in Figure 1.6.

Following the message’s advice, we can type :q!<return>
to force Vim to quit without saving any changes (Figure 1.7), which returns us to the command line.

You may have noticed that we’re now in a position to understand the Most Important Vim Command™ introduced in Section 1.2: no matter what terrible things you might have done to a file, as long as you type ESC
(to get out of insertion mode if necessary)16 followed by :q!<return>
(to force-quit) you are guaranteed not to do any damage.
Of course, Vim is only really useful if we can save our edits, so let’s add some useful text and then write out the result. As in Section 1.3, we’ll work on the .bashrc
file, and the edit we’ll make will add an alias to our shell. In a computing context, an alias is simply a synonym for a command or set of commands. The main use for Bash aliases is defining shorter commands for commonly used combinations.17
In this case, we’ll define the command lr
(short for “list reverse”) as an alias for ls -hartl
, which is the command to list files and directories using human-readable values for the sizes (e.g., 29K instead of 29592 for a 29-kilobyte file), including all of them (even hidden ones), ordered by reverse time, long form. This command, which as you may recognize from an exercise in Learn Enough Command Line to Be Dangerous, is useful for seeing which files and directories have recently changed (as well as being, for obvious reasons, one of my personal favorites). After defining the alias, we’ll be able to replace the more verbose
$ ls -hartl
with the pithier
$ lr
The steps appear as follows:
- Press
i
to enter insertion mode. - Enter the contents shown in Listing 1.4. (On some systems, the
.bashrc
file may include some pre-existing content, which you can simply leave in place.) - Press
ESC
to exit insertion mode. - Write the file using
:w<return>
. - Quit Vim by typing
:q<return>
.
Note: If you make any mistakes, you can type ESC
followed by u
to undo any of the previous steps. (Most programs use Command-Z or Ctrl-Z to undo things, yet another example of the non-native keybindings used by Vim. In contrast, the editors discussed starting in Chapter 2 all support native keybindings.)
~/.bashrc
alias lr='ls -hartl'
After adding the lr
alias to .bashrc
, writing the file, and quitting, you may be surprised to find that the command doesn’t yet work:
$ lr
-bash: lr: command not found
This is because we need to tell the shell about the updated Bash profile file by “sourcing” it using the source
command, as shown in Listing 1.5.18
$ source .bashrc
With that, the lr
command should work as advertised:
$ lr
.
.
.
drwx------+ 15 mhartl staff 510B Sep 4 18:58 Desktop
-rw------- 1 mhartl staff 13K Sep 4 19:13 .viminfo
-rw-r--r-- 1 mhartl staff 46B Sep 4 19:14 .bashrc
drwxr-xr-x+ 117 mhartl staff 3.9K Sep 4 19:14 .
By the way, the .bashrc
file is sourced automatically when we open a new terminal tab or window, so explicit sourcing is necessary only when we want a change to be reflected in the current terminal.
1.4.1 Exercises
- Define an alias
g
for the commonly used case-insensitive grepgrep -i
. What happens if, after making your changes and hittingESC
, you issue the command:wq
instead of:w
and:q
separately? - You may recall the
curl
command from Learn Enough Command Line to Be Dangerous, which lets us interact with URLs via the command line. Defineget
as an alias forcurl -OL
, which is the command to download a file to the local disk (while following any redirects encountered along the way). - Use the alias from the previous exercise to execute the command shown in Listing 1.6, which downloads a longer text file for use in Section 1.6.
$ get cdn.learnenough.com/sonnets.txt
1.5 Deleting content
As with every category of text manipulation, Vim has an enormous number of commands for deleting content, but in this section we’re just going to cover the absolute minimum. We’ll start with deleting single characters, which we can do in normal mode using the x
command:
- Open
.bashrc
and insert the misspelled wordaliaes
. - Get back to normal mode by pressing
ESC
. - Move the cursor over the
e
inaliaes
(Figure 1.8) and pressx
.

x
.
There are lots of fancy ways to delete text, but by repeatedly pressing x
it’s easy (if a bit cumbersome) to delete entire words or even entire lines. On the other hand, deleting lines is enough of a special case to merit inclusion. Let’s get rid of the extra alias
we added by pressing dd
to delete the line. Voilà ! It should be gone (Figure 1.9). To get it back, you can press p
to “put” the line, which also allows you to simulate copying and pasting one line at a time. (Again, this is a minimal subset of Vim; if you decide to get good at it, you’ll learn lots of better ways to do things.)

dd
.
1.5.1 Exercises
- Using Vim, open a new file called
foo.txt
. - Insert the string “A leopard can’t change it’s spots.” (Figure 1.10).19
- Using the
x
key, delete the character necessary to correct the mistake in the line you just entered. (If you can’t find the error, refer to Table 1.1.) - Use
dd
to delete the line, then usep
to paste it repeatedly into the document. - Save the document and quit using a single command. Hint: See the first exercise in Section 1.4.1.

1.6 Editing large files
The final skills needed for your Minimum Viable Vim involve navigating large files. If you didn’t download sonnets.txt
in the exercises from Section 1.4, you should so do now (Listing 1.7).20
$ curl -OL https://cdn.learnenough.com/sonnets.txt
The resulting file contains the full text of Shakespeare’s Sonnets, which is 2620 lines, 17670 words, and 95635 characters long, which we can verify using the word count command wc
covered in Learn Enough Command Line to Be Dangerous:
$ wc sonnets.txt
2620 17670 95635 sonnets.txt
On many systems, Vim shows some of the same basic stats upon opening the file:
$ vim sonnets.txt
The result on my system appears in Figure 1.11. Because of its length, this file is far too long to navigate conveniently by hand.

As before, there are lots of commands for moving around, but I find that the most useful ones involve moving a screen at a time, moving to the beginning or end, or searching. The commands to move one screen at a time are Ctrl-F (Forward) and Ctrl-B (Backward). To move to the end of the file, we can use G
, and to move to the beginning we can use 1G
. Finally, perhaps the most powerful navigation command is search, which involves typing slash /
followed by the string you want to find. The trick is to type /<string>
followed by return, and then press n
to go to the next match (if any).
This might all sound a little familiar, because it’s the same as the interface to the less
program covered in Learn Enough Command Line to Be Dangerous.21 This is one of the advantages of learning basic Unix commands: many of the patterns recur in many different contexts.
1.6.1 Exercises
- With
sonnets.txt
open in Vim, move down three screens and then back up three screens. - Go to the end of the file. What is the last line of the final sonnet?
- Navigate back to the top to change the old-style name “Shake-speare” on Line 1 of
sonnets.txt
to the more modern “Shakespeare”, and save the result. - Use Vim’s search feature to discover which sonnet contains references to Cupid, the Roman god of love.
- Confirm that
18G
goes to the final line of the first sonnet. What do you suppose that command does? Hint: Recall that1G
goes to the beginning of the file, i.e., Line 1.
1.7 Summary
Important commands from this chapter are summarized in Table 1.1. If you’re interested in learning more about Vim, dropping “learn vim” into a search engine is a good bet. The Interactive Vim tutorial is especially recommended.
Command | Description |
ESC:q!<return> |
The Most Important Vim Command™ |
i |
Exit normal mode, enter insertion mode |
ESC |
Exit insertion mode, enter normal mode |
Arrow keys | Move around |
0 |
Go to beginning of line |
$ |
Go to end of line |
:w<return> |
Save (write) a file |
:q<return> |
Quit a file (must be saved) |
:wq<return> |
Write and quit a file |
:q!<return> |
Force-quit a file, discarding any changes |
u |
Undo |
x |
Delete the character under the cursor |
dd |
Delete a line |
p |
Put (paste) deleted text |
it’s spots |
No, you mean its spots
|
Ctrl-F |
Go forward one screen |
Ctrl-B |
Go backward one screen |
G |
Go to last line |
1G |
Go to first line |
/<string> |
Search for <string>
|
1.7.1 Exercises
- Open
sonnets.txt
. - Go to the last line.
- Go to the end of the last line.
- Make a new line that says “That’s all, folks! Bard out. <drops mic>”. Make sure to move the cursor one space to the right so you don’t drag the final period along.
- Write out the file.
- Undo your changes.
- Write out and quit the file.
- Reopen the file and type
2620dd
. - Realize that you just deleted the entire file contents, and apply the Most Important Vim Command™ to ensure that no damage is done.