Site Map - skip to main content - dyslexic font - mobile - text - print

Hacker Public Radio

Your ideas, projects, opinions - podcasted.

New episodes Monday through Friday.

In-Depth Series

Vim Hints

Various contributors lead us on a journey of discovery of the Vim (and vi) editors.

Vim is a highly configurable text editor built to enable efficient text editing. It is an improved version of the vi editor distributed with most UNIX systems.

Vim Plugins I Use - b-yeezi | 2016-10-14

Vim Plugins I Use

Check Your Spelling in Vim - Frank Bell | 2016-01-20

Frank Bell describes how to check your spelling in the Vim editor and to create your own wordlist.

Frank's ~/.vimrc file:

set ruler laststatus=2 number title hlsearch
syntax on
set textwidth=80
set spell spelllang=en_us
set spellfile=$HOME/.Vim/spell/en.utf-8.add


Text file in Vim with spellcheck enabled:

A screen shot of a text document opened in VIM with mis-spelled words highlighted in a different color

Vim "choose the right word" list:

Vim options showing the text change ESC to and then providing a long list of alternatives. At the bottom you are asked to fill in the number of the alternative you wish to use


Nethack and Vi cursor keys - Steve Bickle | 2015-05-27

Hi I'm Steve Bickle and this episode is "Nethack and Vi cursor keys", its my contribution partially inspired by the recent series of vi/vim podcasts and Frank Bell's recent episode Introduction to Rogue Class Linux.
In addition to my piece here, I also want to use this opportunity to point out an excellent podcast about vim, that's complementary to the series on HPR.
I was pleased to see recently that Thomas Gideon's The Command Line podcast is back from a hiatus and want to make sure that others are aware. His 12th of April podcast is an essay entitled "Hope and Fear in the World of vim" where he discusses his use of vim throughout his career as a programmer. You can find this podcast at
The text editor vi was written long ago by Bill Joy in the late 70's before the advent of the PC keyboard and cursor keys, so the default key mappings for left/down/up/right being H,J,K and L are not immediately familiar to a pc keyboard user.
AD-M3A terminal keyboard
The original UNIX machine for which vi was written used the AD-M3A terminal where H,J,K and L had the cursor arrows engraved.
Vi is installed as a default choice on many distros, and where it is not, there is invariably a package available that can be easily added.
Some, if not most, distros come vim installed by default (vim by the way stands for vi improved). This does have the cursor keys mapped nicely for a modern PC keyboard as well as the original keys. Vim is always aliased as vi, so if it's been installed when you enter vi you get vim.
Vi is a pretty light weight bit of code whereas VIM has more dependencies so sometimes vi is still preferred as the default install package. For instance Debian and many of its derivatives have vi rather than vim installed by default.
If you are distro hopping or working on other peoples systems you can generally rely on having vi available, but you can't be sure to get vim so it is useful to be conversant with the vi key mappings, along with a working knowledge of some of the basic commands. Then you will never be at a loss for a text editor when needing to hack around in a Linux box.
For me as an occasional user of vi the most challenging keys to remember to use are the H,J,K and L. cursor keys, since muscle memory has my fingers diving for the arrow keys. This is where the game Nethack comes in, which is what this article/episode is really about.
Nethack is a terminal based dungeon adventure games which uses the same cursor keys as vi and other old UNIX programs. Play this game for a few hours and you will ever struggle with vi cursor keys again.
The goal of the game is to retrieve the 'Amulet' from the lowest level of the dungeon and return to the surface with it for your god.
Nethack presents as a text based adventure with each level gradually being revealed to you in the on-screen character based level map. As you travel through the dungeon more of the level is revealed. As you play, your character gains more experience and levels up its capabilities.
You play as one of a number of types of character, and race. These include many of the usual dungeons and dragons types, archaeologists most likely inspired by Indiana Jones and tourists which definitely owe much to Terry Pratchet. Each role and race has their own initial characteristics, default inventory items, levelsof resilience and ability to learn various skills. For instance a wizard will advance his spell making capabilities faster than a footpad.
Although seemingly a simplistic terminal based game there's more going on in Nethack than is at first apparent. Originally released in 1987 it was actively developed with improvements to game play features until 2003. Since then there have been minor updates and ports for different platforms have been added, however there is rumoured to be a release with further game play improvements some-time this year.
The game has real depth and subtlety that is gradually revealed the more you play. It is not an easy game to win (from my experience to date that may not even be possible) but the more you play it the better strategies you will devise and the more rewarding the game becomes. There's more complexity to this game than almost any modern 3d HD graphic adventure.
Although there is a Nethack Wiki where information about how to play can be sought, the true elite apparently learn through playing. I'd suggest having a go, then when you become familiar with YASDs (yet another stupid death), there's a lot of them, you will have enough experience to answer a few burning question with the Wiki in order to be able to play a more satisfying game.
Although a challenging game, it is not a difficult game to play once you have remembered a few keyboard commands. And this game can be played just about anywhere. Because the game has GPL license there are many ports and flavours available. It is possible to play on most platforms: I have tried it on Linux, Android and even as a Google Chrome app, although the IOS port was not usable on our old iPad or a colleague's new iPhone.
There are various ports for the Windows platform, some of which replace the character based interface with Windows 3.1 style tile interface or a 3d isometric graphic interface. Personally I'd prefer to stick with the traditional character interface since the graphics don't really add anything to the game play. In fact when I play the game on Windows laptop, I use a minimal Debian install running on VirtualBox. I have set it up to auto-run Nethack and shutdown when exiting the game. Then I launch the VM directly with a shortcut containing the virtualbox command on the desktop.
This is how I set up my Nethack VM:
First I created a VirtualBox VM with 1 core 256M of RAM and an 8GB hard drive (I could have easily got away with 2GB actually).
Then I installed a minimal install of Debian, configured networking and installed nethack using apt-get install.
Once nethack was installed I disabled networking so I don't have to wait for a network connection to time-out when if my machine is not online.
To make Debian auto-start with a particular user account you can edit the /etc/inittab and alter one of the tty invocations. I changed the line:
1:2345:respawn:/sbin/mingetty tty1

To login my account 'steve'
1:2345:respawn:/sbin/mingetty –autologin steve tty1

To get Nethack to run on start-up, and the vm to shutdown on exiting the game edit the user's .bashrc file and append these three commands to the end of the file

clear # this ensures that the screen is clean prior to running the game
nethack # to run the game
sudo shutdown -h now # to close the VM when you exit the game

Because Nethack is a terminal based game it doesn't hammer the battery in portable machines, making it an ideal travel game for a commuter.
Even if you are not a gamer its worth a look at Nethack, it might be the one computer game that really grabs your attention.

Vim Hints 004 - Dave Morriss | 2015-05-25

Joining commands together

In this episode I want to look at more movement commands and how to use them in conjunction with commands that change things in the file. I also want to add some more elements to the configuration file we have been building over the last few episodes.

I have covered a lot of ground in this episode, introducing a number of new subjects. This is partly because I felt the series needed to get to the point where you could start to make full use of Vim if you are following along, and partly because the episodes up to this point have been moving a little too slowly! I hope the change in pace and length hasn't put you off.

Full Notes

Since the notes explaining this subject are particularly long, they have been placed here: and an ePub version is also available here:

  1. Vim Help:
  2. Graphical Cheat Sheet:
  3. Vim Hints Episode 3

Five Steps to Vim - Frank Bell | 2015-03-31

The vim editor is based on the venerable vi editor, which dates from the very early days of Unix. Many persons find it intimidating for the absence of a menu bar, a terse command set that is very much its own, and its "modal" design.

Nevertheless, under its plain surface is a powerful and versatile tool. Frank Bell describes his five steps to learning to use and love vim.

  1. Use a .vimrc file.
  2. Train yourself to change modes.
  3. Learn and use a few basic commands. These should be enough to get you going: x, dd, dw (to delete text); cw (change a work); yy ("yank" or copy a line); p and P (to paste text); u (undo); w ("write") or save text; q (quit vim).
  4. Don't force yourself to move the cursor with the h-j-k-l keys if that doesn't feel natural. Use the arrow keys.
  5. Use vim to write stuff.


Vim Hints 003 - Dave Morriss | 2015-03-26

Moving Around

In this episode I want to look at how you move around the file you are editing in Vim. I also want to add some more elements to the configuration file we started building in the last episode.

Full Notes

Since the notes explaining this subject are long (the size limit is 4000 characters), they have been placed here:

I usually create my notes with Markdown and pandoc. As an experiment this time I have used a pandoc template which uses the same CSS that provides the style for the main HPR pages. I hope it makes these notes look better than the very bare HTML I have produced in the past.

  1. Vim Hints Episode 1
  2. Vim Hints Episode 2

Vim Hints 002 - Dave Morriss | 2015-03-12

Vim Ate my Homework

In this episode I want to look at how to keep your work secure with Vim. Next episode we will look at how to create and edit files.

Avoiding data loss with a backup

The best place to start is with the configuration file which we met last episode. As we saw, this is usually $HOME/.vimrc. However, it can also be $HOME/.vim/vimrc, which is actually recommended since it keeps all Vim files in the same place. I use the former, since that's the way I have always done it.

Let's add some options to this file. Configuration options consist of command mode commands. Actually, to be precise about it, any Vim Script expression may be written there.

First it's a good idea to ensure that Vim runs with all of its standard features enabled. The option for this is called compatible (meaning compatible with Vi), which we need to turn off. This is done with the option:

set nocompatible

Next, it's highly advisable to make Vim generate a backup file whenever it opens a file for editing. The backup file has the same name as the original file with a tilde appended. The configuration command is:

set backup

The backup file is a copy of the file which existed before editing started.

By default the backup file is saved in the same directory as the file being edited. If this is a problem (and to me this is not), then it is possible to tell Vim to save backups in a fixed place. This is done with the command set backupdir= followed by a list of directories. For example:

set backupdir=~/.backup,.,/tmp

If you were to add this to your configuration file, Vim would save backups in a top-level directory ~/.backup (which must already exist), then if this fails it will save in the current directory, falling back to /tmp if all else fails. Whether you do this is up to you. I would suggest you do not, at least not until you are more experienced with Vim.

Undoing and redoing changes

Vim can undo changes you make to a file. This is useful if a change was the wrong change or in the wrong place. It can also redo the undone change.

The u command in normal mode undoes the last change. The redo function is invoked by pressing the Ctrl key while pressing r. This key sequence is normally represented as CTRL-R.

Vim keeps a record of the changes, so successive u commands undo successive changes back in time. Conversely, CTRL-R redoes the undone changes forward in time.

Normally the change history is lost when Vim exits, but two configuration options can be used to save it. The undofile option ensures change history is written to a file and undodir shows the (pre-existing) directory which is to hold these files.

set undodir=~/.vim/undodir
set undofile

It can be a little surprising if you press u in a file you have just opened in Vim to find that it undoes something you changed last time you edited it! However, on the whole I think this is a great feature.

File recovery

The Swap File

By default Vim uses a recovery mechanism where it generates a swap file. Under Unix and Linux this file has a name built from the name of the file being edited with a dot prepended (making it a hidden file) and with the extension ".swp". So, if you were editing the file testfile the swap file would be a file called .testfile.swp in the same directory.

It is possible to make Vim write the swap file elsewhere, such as on another partition. You can also turn this recovery capability off. It is probably advisable to use the default settings while you are learning Vim.

The swap file is updated after typing 200 characters or when you have not typed anything for four seconds. The swap file is deleted as soon as Vim stops editing the file.


Case 1: there are changes in the swap file

If something bad happens during an editing session, such as the loss of power, the swap file will remain after the event. If you know that you need to recover your edit session then you can simply type the following in the directory where the file you were editing exists:

vim -r filename

You will see a message such as the following:

Using swap file ".testfile3.swp"
Original file "~/testfile3"
Recovery completed. You should check if everything is OK.
(You might want to write out this file under another name
and run diff with the original file to check for changes)
You may want to delete the .swp file now.

Press ENTER or type command to continue

See the explanation on the Vim wiki.

Alternatively, when you try to edit a file you were editing at the time of the failure Vim will detect the presence of a swap file and alert you with a message such as:

Found a swap file by the name ".testfile2.swp"
          owned by: hprdemo   dated: Fri Feb 13 15:33:41 2015
         file name: ~hprdemo/testfile2
          modified: YES
         user name: hprdemo   host name: i7-desktop
        process ID: 16181
While opening file "testfile2"
             dated: Sat Dec  6 18:34:32 2014

(1) Another program may be editing the same file.  If this is the case,
    be careful not to end up with two different instances of the same
    file when making changes.  Quit, or continue with caution.
(2) An edit session for this file crashed.
    If this is the case, use ":recover" or "vim -r testfile2"
    to recover the changes (see ":help recovery").
    If you did this already, delete the swap file ".testfile2.swp"
    to avoid this message.

Swap file ".testfile2.swp" already exists!
[O]pen Read-Only, (E)dit anyway, (R)ecover, (D)elete it, (Q)uit, (A)bort:

Vim here is indicating that there are unsaved changes that can be recovered. It is also warning that if someone is editing the same file (such as you in another window) this might account for the presence of the swap file.

Assuming it's appropriate, you can recover the changes and continue editing by pressing r at the above prompt. You will see messages such as the ones above relating to the vim -r filename example.

Be aware that if you continue editing the original swap file will continue to exist and you will get the same message again next time you edit the file. Vim will create a new swap file (called /home/hprdemo/.testfile2.swo in this case) to protect the new editing session.

This situation can be a little confusing if you have not encountered it before. There are a number of ways you can resolve this:

  1. You can save the recovered file and exit Vim (type :wq). You can then edit the same file all over again. You will see almost the same message as before, but you can now delete the swap file by pressing d. The message you see the second time round will contain the additional warning that the file you are editing is newer than the swap file - that is because you just saved a new copy of it!

  2. You can save the file and exit Vim as above, but then explicitly delete the swap file. In the example you would do this by typing: rm .testfile2.swp

  3. As before you can save the file but this time without exiting Vim (type :w). Then tell Vim to re-edit the current file with the command :e. You will then see the warning about there being a swap file, and you can type d to delete it.

Case 2: there are no changes in the swap file

If, when you see the message about finding a swap file you see that there are no changes to recover you can just delete the swap file by pressing d. You can then continue with editing the file as normal.

Don't Panic!

This recovery process is complex because Vim is trying to ensure that you are protected against losing your changes.

As it says in the Vim manual DON'T PANIC!


  • The configuration file should contain the following:
set nocompatible
set backup
set undodir=~/.vim/undodir
set undofile
  • Use u in normal mode to undo a change
  • Use CTRL-R in normal mode to redo an undone change
  • Re-starting Vim after a crash will invoke a recovery dialogue

Vim Hints 001 - Dave Morriss | 2015-02-26

Introduction to Vim

This is the start of the Vim Hints series.

As a Linux user there are many editors available to you. Which one you want to use depends on your needs and the amount of time you want to dedicate to learning how to use it.

One of the editors from the early days of Unix is vi, written in 1976. Contemporary with it is Emacs, also originating in 1976. However, it seemed to become the norm (in my experience anyway) that vi rather than Emacs was provided as standard with versions of Unix, and this has often continued into Linux.

I originally started using Unix around 1988 and found vi available to me. I learnt how to use it in a rudimentary way since I knew I'd find it on any Unix systems I came across.

Many derivatives and clones of vi have been created. The one which has become the most popular and available is Vim, the name of which is an acronym for Vi IMproved, created in 1991 by Bram Moolenaar. This is what I use, and I have not wanted to learn another editor since adopting it, even though I have experimented with several. This is the editor we will be looking at in this series.

What's the series about?

The thinking behind this series is:

  • You may already be using Vim; there are features you may not be aware of that can be revealed here
  • You may be using a different, simpler editor; you might want to use Vim and gain from its advanced features

Of course, you may prefer to learn Emacs instead. That's fine; you should choose the tool that best suits your needs. Both Emacs and Vim have quite steep learning curves, but the broad range of capabilities you gain from knowing either is considerable.

I am not an expert in Vim. In fact I am continuing to learn new Vim features on a regular basis. However, I have been using it for many years and would like to share some of what I have learnt.

Why use Vim?

With simpler editors you can move about a file, add, remove and change text and save the results. The editor might have syntax highlighting and some degree of knowledge of the programming language you are typing. You might have spell checking as well.

With Vim and other more advanced editors you have all of this and a lot more. You can perform global changes throughout a file, process many files at once, add plugins to the editor to change its behaviour, and so on. Also, there is a language behind the scenes which can be used to build extensions.

Using Vim

Usually, typing the command vi at the command line actually invokes vim. Vim runs in vi-compatible mode by default, which results in Vim enhancements being unavailable.

Vim uses a configuration file, which is called .vimrc on Linux. (Vim will also run on Windows, OSX and other operating systems but we will not be covering these implementations in this series.) Vim also has a GUI interface invoked by the command gvim, and it has its own configuration file .gvimrc.

I you don't have a .vimrc create one with touch ~/.vimrc before you start. This will stop Vim running in vi-compatible mode. We will look at what the .vimrc can be used to do later.

You can start Vim on its own without pointing at a file, but normally you use it to edit a file, which need not already exist. So, to create a new file called testfile invoke Vim with the command: vim testfile

Once running, Vim shows the contents of the file. All the lines on the screen where there is no content are marked with a tilde "~" character. If you are creating a file the first line on the screen will be blank, and last line will contain the name of the file followed by "[New File]" and some other details which we will examine later:

"testfile" [New File]       0,0-1         All

All the rest of the lines will contain a tilde.

Vim is a modal editor. The mode you usually start in is normal mode where you can move around the lines of the file and perform actions, but nothing you type is actually written to the file. In fact, the keys you type are actually editing commands. This is one of the features of Vim that causes problems for new users.

Since this is a new file there is not much you can do other than enter text, and to do this you need to switch to insert mode. Do this by pressing the i key. The message -- INSERT -- will appear on the bottom line of the screen. Now type some text, pressing the Enter key at the end of each line.

You might notice that in insert mode you can press the arrow keys and move back to text you have already typed. This is a Vim feature and was not available in the original vi editor.

When you have finished entering text, press the Esc key to exit from insert mode. Now you can move around in normal mode, but remember that the keys you press are now commands not data to be entered into the file.

To move around in normal mode use the arrow keys or the home row keyboard keys: k to move up, j to move down, h to move left and l to move right.

This brings us to the last mode we'll look at: command mode. To enter this mode press the : (colon) key in normal mode. This moves the cursor to the last line of the screen, which starts with the colon you just typed. Here you can enter another class of commands. This time, we'll just look at how you can save the file and exit Vim.

Saving the file is achieved with the w command, and to exit from Vim the q command is used. These can be typed together, so :wq writes the file and exits.

If you were to use :q on its own, having entered data into Vim, this would not work. Vim prevents you from throwing away your work this way. If you really meant to quit without saving then the q must be followed by an exclamation mark ("!"). So :q! lets you exit Vim without saving.

Summary so far

  • Vim usually starts in normal mode
  • Arrow keys or h, j, k and l for left, down, up and right for navigation in normal mode
  • i enters insert mode
  • Esc exits from insert mode and reverts to normal mode
  • : in normal mode enters command mode
  • :w in normal mode writes the file
  • :wq in normal mode writes and exits
  • :q in normal mode exits but only if nothing was changed or added
  • :q! in normal mode exits regardless of any changes


  • I was wrong about the contents of the last line of the Vim screen in the audio. The notes have been corrected.



Other resources