Potatowire finally leaves the crib, joining Gabe and Erik to discuss command-line text editing with vim. We learn how he started, why he uses a forty-year old text editor, and some cool things you can do when your hands never have to leave the keyboard.
This is weird
This is a strange episode for me. Usually I am the guy who comments from
outside the conversation, and I am often the one who stitches the links and
asides together with narrative. In this case Gabe and Erik asked me to come
into the conversation as it happened, rather than afterwards.
This also meant that I had to listen to my own recorded voice, which I usually
try to avoid. Anyway, what follows is a long discussion about Vim and the
terminal. I am very strong proponent about Vim, but I try not to browbeat
people about it, since I know that it works best for me, and not necessarily
for everyone else. Though it should be. Damn it, that slipped out.
Also, if it seems like my attention occasionally wandered, my kids came home during the middle of the recording, and my daughter, in particular, thought she ought to have my undivided attention periodically. I am not a professional.
Introducing Potatowire
Listen to this section on SoundCloud: 0:00
“I like my friends online where I can keep an eye on them.”
The story about how I became so fascinated by Vim and the command line is not
terribly glamorous or interesting. I think Dr.Drang has a much better story, leaving aside some
of the great material that
exists from the formative years of these tools.
Like many kids, I liked video games before I liked computers, and in my case,
the two first became connected by the Commodore 64, which was both computer and
game platform. It wasn’t really great at either function, but I didn’t know
that. I loved Jumpman and
Popeye, and that even caused me
to dig into the Programmer’s Reference Guide
to try to write my own game.
Memories
I may have stunted my programming
growth
by starting too young though, because I didn’t go back to programming again
until college.
It was also in college that I really realized that the command line lurked
there underneath the surface of all that pretty GUI. I don’t remember what I was
trying to do, but I was having some trouble accomplishing a task with the
wonderful computer that I had
been given, and the guy who lived across the hall from me asked me why I didn’t
just do whatever it was in DOS instead of
in Windows 3.11. I dug in a little,
and the command line had me hooked.
Similarities
If a friend of mine hadn’t done exactly the same thing to me freshman year in college (and provided me with a lot of advice over the next few years) I’d be a much less capable computer user today.
Fast forward to 2004, and I had a little extra money that I excitedly plunked
down to buy a PowerBook G4 1.5
17”.
It was a revelation. As I poked around this new-to-me OS X I discovered the hidden settings made possible by defaults
write. I was in love with the command line
all over again.
The management regrets the error
I said that I bought my new Mac in 2007, but I meant 2004. Was there something
else that happened in 2007?
My computer use took another leap forward in its evolution when I read a post
on O’Reilly’s Radar, which has since been lost from both my
mind and my bookmarks, about this editor called Vim that I really knew nothing
about. This was interesting, but nothing really changed for me until I read Steve Losh’s post about Coming Home to
Vim. I thought it was
wonderful and compelling and I switched text
editors on the spot.
Section Links
MacVim
Dr. Bunsen - The Text Triumvirate
zsh and Oh-My-Zsh
Vim
tmux
Learning about the tools
Listen to this section on SoundCloud: 11:36
tmux - The Terminal Multiplexer
Tmux is a terminal multiplexer. That didn’t mean much to me when I was first told that either, but the idea is that you can have multiple terminal sessions in a single terminal window or emulator. You can organize these into panes by splitting the windows into sections, or into windows, which most of us would think of as tabs. Another main feature is that you can detach from a session, and anything you have in progress will continue on while you are away. When you later attach back to your session, everything is as you left it, even though you may have closed your terminal window, restarted your computer, or have decided to ssh-in using your phone.
Much of the discussion in the audio was devoted to Vim, and tmux alone is worthy of its own show, but if this has piqued your interest, there are countless resources available online, from basic crash courses to the more exhaustive. While I do wonder about the cost, the Pragpub tmux book is a very good way to go from zero to tmux-functional in a couple days. In case you’re wondering, I remained too cheap to buy it, but a friend gave it to me, and I can personally vouch for it as a good starting point.
Vim - Everything Improved
Now, those of you familiar with Vim know that it isn’t very easy to switch to without significant forethought. For starters, it is ugly right out of the box. Really ugly. Second of
all, once you try to type something into the ugly window, say, hello
world you will actually see this:
Windows version, so even uglier
This is because Vim opens into Normal
mode.
This is correct, right, sweetness and light, etc.; you just don’t know it yet. So, a
text editor that won’t let you actually type text. Just bear with me. What happens
when you start typing, hello world in normal mode is nothing until you get to
l when it tries to move the cursor to the right, but it can’t because that is
virtual space, since you
haven’t yet “typed” anything. It’s not until you get to the o that anything
other than a beep or visual bell happens, because when you type the o you
are telling Vim to “open a line below this one and go into Insert
Mode.”
After this, you can type world with impunity. Insert mode is where you can
type like usual.
At this point you may just want to quit Vim an move on. Wait,
how in the Sam Hill do you quit Vim? For that you need to enter Command-line or Command mode by typing :. Then you’ve got to type q or q! to quit without saving.
Vim doesn’t seem to like beginners.
With this sort of first impression, why does anyone use Vim if they don’t have
to? Well, in my mind the biggest reason is that Vim rewards hard work. It
rewards hard work with efficiency and with value, and the main reason I
say this is because of how the Vim vocabulary functions.
Vocabulary
Vim has its own vocabulary, and it applies everywhere, once you learn it.
There are a lot of good resources about this language, but the basics are pretty easy to grasp. The general idea
is that there are verbs, objects, and modifiers. To keep it simple (OK, simpler)
we are going to talk about all of these in Normal mode.
The verbs fall into the general categories of movement and action. This is my distinction. The most
familiar way to move around is with the arrow keys, or in better Vim fashion,
using the h, j, k, and l keys.
hjkl
This isn’t very efficient though, and Vim lets you make bigger moves. A basic
but useful subset of these bigger moves can be found in this table (each row
has a command and its opposite):
Key
Moves you to:
Key
Moves you to:
gg
Top of the buffer (file)
G
Bottom of the buffer
0
Beginning of the line
$
End of the Line
(
Beginning of the “sentence”
)
End of the “sentence”
{
Beginning of the “paragraph”
}
End of the “paragraph”
W
Forward to the beginning of the next WORD
B
Backwards to the beginning of the next WORD
I worked from big movements to small, and I left plenty of things out. Just
like when learning a foreign language, you can function with limited
vocabulary. You just won’t be very eloquent.
This small subset of the Vim “language” will allow you
to move around, and once you have mastered these, you can expand your word list using one
of the many
great cheatsheets that exist, or you can use my
method of putting a few new things you want to learn on a Post-it stuck to your
monitor.
One other note on the table above, is that Vim distinguishes between
words and WORDS. There is a pretty good description of what this means
here, but stated simply, a “word” is
literally a word, while a “WORD” is whatever surrounded by whitespace. I
think WORD is the better choice for us right now, because it is usually what you want.
This is great, you can move around, but why is this any different from using
keyboard shortcuts? The biggest way they’re better in my opinion is that these
movements can be combined with the actions I mentioned earlier. Some
examples of actions would be d to delete, y to yank (Vim for copy), c to change,
and v to select. You can combine the actions with the movements,
so for example, y$ yanks from the cursor to the end of the line, d}
deletes from the cursor to the end of the paragraph, etc. One final note
here, when you delete in Vim, you are in effect, cutting the text,
because the contents are moved into the unnamed register. I wrote more
about that in the clipboard episode of
TD.
The last part of Vim vocabulary I’d like to highlight is the object.
Now, the movements above would qualify as objects when combined with the
actions in my examples, but some actions always require objects. Two good examples of
this are t, meaning “till,” and f, meaning “find.” These both operate
similarly, and both are probably best explained by an example.
Let the x in “hello world” represent the cursor position.
For hxllo world, tw yields helloxworld, and fw yields
hello xorld. To elaborate a bit, the cursor moves forward until it finds the character
that was the object, and it either stops right before the character or
right on it. Because Vim seeks to be logical, F and T work the same
way, only the cursor moves backwards. This relationship between uppercase and lowercase letter commands recurs often, and it is another example of how you can learn a Vim convention once and apply it everywhere
The last thing I will say about vocabulary is to point out that this
only scratches the surface. I will leave the following as exercises for the
reader: try typing any of the previous commands with a 2 in front, and
try typing a . after any of them.
If you want to explore this language analogy a little more, try
these links:
Vim Text Objects: The Definitive Guide
Vim as
Language – This is part two of a series that Ben
McCormick
just started, but man, it looks like it will be a great help for
those starting out.
Herr Doktor
I talked a bit in the audio about Dr. Drang’s thoughts on why Vim doesn’t work with the way he writes, as highlighted in this post. I seem to write in a similar way as he does, but while the modes bothered him, I always am ready to edit, because I spend most of my time in Normal mode.
I used to always find myself in the the wrong mode, but that changed for me once I decided that I would train myself to go back to Normal mode every time I wasn’t actively typing. This worked for me. Now my left pinky continually pecks at the Escape key any time I am deep in thought. I get a lot of weird looks in meetings, where there is usually no keyboard in sight…
While I’m talking about Dr. Drang (as I so often do here), you really ought to go back and read his series “Text Files and Me.” Seriously, go read the whole thing, I’ll wait.
Part 1
Part 2
Part 3
Part 3.5
Part 4
“Next thing you know I’m playing a song in Pandora”
Tweaking your setup
Listen to this section on SoundCloud: 37:37
As I earlier said, Vim is ugly out of the box, and some of its settings could benefit from some tuning. Vim makes this pretty easy… well Vim easy, at least. There are global settings for Vim which can be applied to all users, but most people keep all of their personal settings in a .vimrc file which lives in the home directory. This is just a plain text file that contains customizations written in the Vim Language, and sometimes I think 10% of Github is hosted .vimrc files. There is plenty of ready help online.
My Vim Setup
Custom colors
I have been using Ethan Schoonover’s Solarized color scheme ever since I first saw it, but I recognize that others remain color-curious. For those in that camp, I don’t think there is a better comparison-shopping resource than this. All of these themes are available in this repository, so switch around to your heart’s content.
Vim makes installing a new color scheme as simple as copying the folder to the ~/.vim/colors directory and typing :colorscheme solarized or :colo solarized. Vim has a short version of all common commands, and the convention for writing these is of the form :colo[rscheme], with the part in brackets being optional. I’ll write it this way from now on.
For Sublime Text refugees
I mentioned the Spacegray color scheme, and if you want it go here, because it is based on the base16 project.
Keyboard Mapping and the Help System
Gabe asked about seeing a list of all the key mappings, and the way to get a listing of your custom mappings all at once is to type :nmap, :imap, :vmap, etc. You can see a summary of all default mappings by utilizing :h[elp] index. I didn’t know about these
commands when we recorded the episode and had previously just taken a look in my .vimrc when something in Vim surprised me. Now, these commands provide a listing and general summary, but it doesn’t really teach you anything. For that purpose, let’s venture into the help system.
The help system in Vim is very capable, and I have no problem saying that it is the best in any software application I have ever used. This being Vim, some homework is required. To drive that point home, you can even run :h[elp] help (which opens helphelp.txt), but I’ll highlight a number of techniques here so that you can be pretty capable right off the bat.
First of all, if you are browsing help just to learn, you probably want to have it take up the whole window instead of having it split. If so, type o.
Conventions
C is how the Control Key is represented in Vim convention and the
indicates the use of a modifier or special key, Control plus w then o in this case,
and you’ll see this sort of thing if you read about Vim on the interwebs. I mention this becuase my small mind was confused by this for a little while. Anyway
is the way that you talk to the window, and in this case you are typing saying “Window, only,” because you want the active window split to be the only window split.
Regardless of how you get there, once you are in the help files, you can get away with just typing / to search and then navigate by going forward with n and backwards with N. That works fine, and I did it for years, but it is much better to utilize the tags in Vim help. With your cursor in |bookmark|, typing
will search for where that tag is defined in the help files. Even better, if you see an interesting term in the documentation,
will search the help tags for whatever WORD (remember that distinction earlier) the cursor is on.
Now, as you move around from tag to tag, you may want to go back, and the way to do that is either with
(think “Control Tag”), which jumps you back one older entry in the tag stack, or with
(think “Control Older”), which jumps you back one older entry in the “jump list” of old cursor positions ( takes you to newer cursor positions in the jump list). Jumping by cursor position is good if you have used / to search a little within the help file.
All of this assumes that you know what the help subject you want is, but Vim provides some tools if you don’t know exactly what you want. The first step here is to ensure that “wildmenu” on with :set wildmenu. Wildmenu in Vim allows for
completion in command mode, and it is fantastic. In this case, if you type :h patt, Vim will cycle through the available options with each . Even better, because the list of potential matches is sometimes long, you can
type :h patt and see a list of the available possibilities.
Another option when you are shooting blind if the use helpgrep by typing helpg[rep] {pattern}. You can navigate through the matches with the :cn[ext] or :cp[revious] to jump around between the matches.
Or use :cw[indow] to get the list of matches.
One final assistance I can recommend is the Beautiful Vim Cheat-Sheet. I used an older one when i was starting out, but this version provides a nice logical layout of the basics for getting around Vim. I like it.
Plugins
I talked about this in the audio, but in general, I am against adding plugins to Vim too early. In a similar vein, I don’t think it is wise to just start with someone else’s .vimrc. I did that when I started and to this day, I have lingering confusion over whether some mappings are a part of baseline Vim or not.
If I had to do it over again, I would work with a barebones installation (with Solarized installed though. I am not an animal), and make changes to my installation only when I reached friction points in my workflow. I would also learn the help system right away. As a counterpoint, there are full Vim “Distributions” like Janus, so you are free to go in the completely opposite direction.
With my preamble out of the way, here are the plugins that I mentioned on the show:
Pathogen - This plugin management system developed by Tim Pope is probably the reason that the Vim bundle ecosystem is so healthy. Pathogen makes adding a plugin as easy as copying a folder into your ~/.vim/bundles folder.
Vundle - In my opinion, the only thing better than managing plugins through the filesystem is managing them right in the .vimrc. Using Vundle you simply put the location of a plugin’s repository in your .vimrc and Vundle clones the repository and puts everything in its proper place after running :PluginInstall from within Vim.
YouCompleteMe - YCM, as the cool kids call it, is a code-completion engine for Vim, and I am in love with it. It works in virtually any language, and it is pre-compiled so that it is fast. I have run it locally and on a remote server, and it always seems snappy and responsive. The project page has some gifs showing it in action, so take a look there to see some pictures worth far more than a thousand of my words.
UltiSnips - This text expansion tool is the next of new-to-me plugins that I am madly in love with. Similar in capability to the much-beloved TextExpander, this tool allows fill-in snippets, shell script expansion, and quick editing snippets while you work. The author has some great screencasts beginning with this one, and the always-great Drew Neil has begun a series on Vimcasts. My favorite feature may be its integration with YouCompleteMe, and which allows fuzzy-search to find snippets. As I talked about in the audio, I can’t remember keyboard shortcuts for the life of me. The starter set of snippets I mentioned in the audio can be found here.
Easy Motion - This plugin takes Vim’s already great movement to the next level with some additional functionality and creative text highlighting. I am beating a dead horse, but learn baseline Vim motion before installing this. I cannot be held responsible for my actions if you ignore this advice.
Managing Dotfiles
Managing and tweaking your dotfiles can be an addictive pursuit if you’re not careful. We talked about it a little during the audio, but it is probably worth its own show (Yeah, right. Like Gabe and Erik will ever let me near a microphone after this episode). For now I’ll just point out a couple of good resources to learn more.
Git - It used the goal of putting my dotfiles online as the impetus to actually learn Git, and I now know enough fix every third thing I screw up. I like Bitbucket’s Git tutorials best, and their Bitbucket 101 documentation is great for learning about either Git or Mercurial.
Bitbucket - I keep everything on Bitbucket, because it allows me to have private repositories for nothing, and as I just demonstrated, I like their documentation. I don’t know if they are really better about their institutional misogyny, but I think it’s safe to say they are better than some others that come to mind.
dotfiles.github.io - Earlier criticism aside, I don’t know of a better place to go to learn more about how smart people manage their dotfiles. I don’t have to give my opinion about simply installing someone’s complete dotfiles system, do I?
Working Remotely
Listen to this section on SoundCloud: 61:55
I do some work when mobile, as in while moving, so I often am subject to the pain of spotty internet connections. I have found no better tool than Mosh to help me deal with this issue. Mosh, for “Mobile Shell” details a number of features on its page, but my favorite is “intelligent local echo.” This is what I talked about in the audio as “intuiting” the response, but the idea here is that it doesn’t wait for server response before locally echoing what was typed. This means that typing delay virtually disappears. You can find some technical details online, or you can consider it magic, like I do.
I also alluded to my love affair with DigitalOcean, and it is love, to be sure. I don’t like to be tied to a particular platform or OS at this point in my life, so I am slowly moving everything that is essential to my workflow onto my own online host. Right now, that host is DigitalOcean. They give me complete control of my own “droplet” (read: sudo and root access), so it is my server and their hosting. It also feels very fast, and I think this is probably due to magic too. I can use Vim on this server, with no noticeable lag, from any device, and the installation script I talked about in the audio can clone this setup to any Ubuntu system, so I don’t feel any lock-in. The script is four-for-five now, so maybe it does work…
Producer’s Note
Well, that’s it for this week. If you have anything that you’d like to add to or correct in the show notes you can find me on Twitter @potatowire, or feel free to send an email to me at potatowire dot com.