This is the fourth part in the series Taming Vim, a series focused on improving the intermediate Vim user’s understanding and operation of the text editor.
I’ll mostly be paraphrasing and summarising the introduction to buffers, windows and tabs from the Vim help.
There are some building blocks to understand with regards to buffers, windows and tabs which will likely influence how you perceive and use them, as well as how they differ from the more traditional perceptions:
By default you start with one tab, one window and one buffer when editing
a file with vim file1.
You can open multiple buffers by invoking Vim with multiple arguments:
vim file1 file2 file3
Currently loaded buffers can be listed using the :ls command:
:ls
1 %a "file1" line 1
2 "file2" line 0
3 "file3" line 0
This output shows us a multitude of information:
Ctrl-^ (that is, Ctrl-Shift-6), e.g. 3 Ctrl-^ will switch to the
“file3” buffer. :edit #3 (or :e #3) is the equivalent command-line.% indicator. Only one
buffer can ever be the current window.a. It is
possible for multiple buffers to be active if you have multiple windows or
tabs.Examining :ls after splitting our current window horizontally with Ctrl-W s
and switching to buffer 2 with :e #2 we can see new information:
:ls
1 #a "file1" line 1
2 %a "file2" line 1
3 "file3" line 0
Firstly, notice that two buffers are active now because of our window split and
buffer switch. Secondly, notice the “alternate buffer” indicator #. You can
switch back and forth between the active and alternate buffer with Ctrl-^
(without a number preceding it) or :e #.
Writing some text into the buffer, without saving, we now see the modification
indicator +:
:ls
1 #a "file1" line 1
2 %a + "file2" line 1
3 "file3" line 0
Attempting to change away from the modified buffer, with :bnext for example,
results in an error: “E37: No write since last change (add ! to override)”,
sure enough :bnext! changes the buffer as expected. I personally find this
“protection” annoying, fortunately there is the hidden option which
allows you to switch away from a modified buffer (called abandoning it) forcing
it to become hidden automatically.
A good way of switching between buffers by name is :buffer (or :b) followed
by the name, the upside of this is that Vim will tab-complete the name for you.
(Although there is a better way.)
NOTE: It is important to understand that q! becomes more dangerous with
this option, since modified hidden buffers will discarded when quitting without
writing.
If you use the command line frequently it might be useful to know can list the
argument list, as given at the command line, with
:args and move to the next and previous buffer specified by command
line arguments with :next and :prev respectively.
| Command | Action |
|---|---|
N Ctrl-^ |
Switch to buffer number N |
:e[dit] #N |
Switch to buffer number N |
Ctrl-^ |
Switch to the alternate buffer |
:e[dit] # |
Switch to the alternate buffer |
:bn[ext] |
Go to the next buffer |
:bp[revious] |
Go to the previous buffer |
:bf[irst] |
Go to the first buffer |
:bl[ast] |
Go to the last buffer |
:bd[elete] |
Remove the buffer from the buffer list |
:b[uffer] B |
Switch to the buffer with the name B |
Most of the window commands are quite similar to the buffer commands, understanding the buffer commands will help you understand and remember the window commands.
Use the -o or -O command-line options to open
files in multiple horizontal splits or vertical window splits respectively.
Windows are an important way to make efficient use of your screen real-estate
and increase your productivity. Perhaps the most basic and useful window
command is split: pressing Ctrl-W s equally splits the current window
horizontally, while Ctrl-W v equally splits the current window vertically.
Use Ctrl-W T to move the current window to a new tab.
Moving between windows is quite logical, after pressing Ctrl-W the normal Vim
movement keys (or the more conventional arrow keys) h, j, k or l will
move you to the window left, down, up or right from the current window. You can
also use Ctrl-W w to move to the window below / right from the current one,
or Ctrl-W W to move to the window above / left of the current window. If you
find yourself moving back and forth between two windows often, you can use
Ctrl-W p to switch to the previously accessed window.
A cousin of Ctrl-^ from the buffer section, Ctrl-W ^ (or Ctrl-W Ctrl-^)
splits the window and edits the alternate buffer, similarly N Ctrl-W Ctrl-^
splits and edits buffer number N.
| Command | Action |
|---|---|
Ctrl-W s |
Split a window horizontally |
Ctrl-W v |
Split a window vertically |
Ctrl-W p |
Move to the previously accessed window |
Ctrl-W T |
Move the current window to a new tab |
Ctrl-W h |
Move to the window to the left |
Ctrl-W j |
Move to the window to the below |
Ctrl-W k |
Move to the window to the above |
Ctrl-W l |
Move to the window to the right |
Ctrl-W w |
Move to the window to the below / right |
Ctrl-W W |
Move to the window to the above / left |
Ctrl-W ^ |
Split the window and edit the alternate buffer |
N Ctrl-W ^ |
Split the window and edit buffer number N |
Use the -p command-line option to open arguments in separate tab
pages.
It’s lonely at the top and tabs are no exception. Tabs lack the plethora of commands and options that buffers (and even windows) have but this doesn’t make them any more useful.
To edit a file in a tab you can use :tabedit filename, much like :edit
filename, and :tabclose to close a tab and all its windows. gt and gT
will switch to the next and previous tab respectively, a number followed by
gt will switch to that tab. I find these shortcuts painful compared to the
buffer and window commands and use mappings to make things easier:
(These mappings are for MacVim (the
Dmodifier is the Command key) but serve as a useful guideline you can adapt to your platform of choice.)
noremap <D-1> 1gt
noremap <D-2> 2gt
noremap <D-3> 3gt
noremap <D-4> 4gt
noremap <D-5> 5gt
noremap <D-6> 6gt
noremap <D-7> 7gt
noremap <D-8> 8gt
noremap <D-9> 9gt
noremap <D-0> :tablast<CR>
" MacVim has these bindings by default.
noremap <D-S-]> gt
noremap <D-S-[> gT
Now cycling through tabs is accomplished with the more conventional Cmd-{ and
Cmd-} commands, and switching to tab 1 with Cmd-1, tab 2 with Cmd-2, etc.
Don’t be intimidated by the number of commands and options for buffers, windows and tabs. Start slowly with a few of the most useful commands and regularly think about your most frequent actions, introducing new commands (or even your own mappings) when you’re comfortable with the others or want to improve your workflow.
Challenge yourself to find new ways to arrange your buffers within windows or windows within tabs. Unlike a lot of other editors or IDEs you are not limited to one file per tab. There’s not even any reason to only use tabs with files, you can put your quickfix window, grep results, help text, file listings, etc. in tabs too!
Drew Neil has some great screencasts on the topics of buffers, windows and tabs.
Experiment!
These long posts can be time-consuming and tedious both to read and write, I’m going to make an effort to write more concisely and on smaller topics.
This is the third part in the series Taming Vim, a series focused on improving the intermediate Vim user’s understanding and operation of the text editor.
Mapping, or key mapping, is used to change the meaning of keys.
We can, for example, map the “F1” key to do something silly like delete from
the first a to the next a:
:map <F1> 0fadfa
Now we can go to the beginning of the line (0), go to the next a (fa),
delete to the following a (dfa) just by pressing “F1” in normal mode. Vim
has other modes (see what happens if you press “F1” in another mode) but we
only intended this to work in normal mode. Consulting the map
overview shows that :map defines the mapping for most modes
when what we actually want is :nmap. However, it is still possible to make
our command work in insert mode (visual mode is left as an exercise):
:imap <F1> <Esc><F1>i
Exit insert mode (<Esc>), perform our “F1” mapping, enter insert mode again.
We can also map commands that need to be executed on the Vim command line:
:nnoremap <F2> :%s/teh/the/g<CR>
Pressing “F2” will replace all instances of “teh” with “the”, notice that
<CR> appears at the of the command to emulate pressing the return key,
without this we’d just be left in the command line without executing anything
(which can be useful in some circumstances.) Other special
keys (like the up arrow, “F1”, etc.) and special
characters (like “escape”, “return”, etc.) are well
documented. More often than not mappings should be declared with the “noremap”
variants to avoid accidental recursive or nested mappings.
A special key often used by Vim users (and plugin authors) for their own
purposes is <Leader>. The map leader defaults to backslash (\)
but can be changed (I use the more accessible comma (,) key) by setting the
mapleader variable; there are some caveats about setting this, be sure to
consult the help.
Vim mappings are not limited to just a single special key or even a single
character, they can be a sequence of just about any keystrokes! Following on
from this, Vim allows ambiguous mappings, meaning that it is
possible to have a mapping for aa and ab and Vim will wait 1 after the
first a to see which one you meant.
Anything you can type into Vim with your hands can be mapped!
The make command can be a useful for things other than running GNU make. I use it to run Pyflakes and JSHint, opening the quickfix window if there are any errors, simply by pressing “F5”:
nnoremap <F5> :silent make %<CR>:cwindow<CR>
" Quickfix navigation.
nnoremap ]q :cnext<CR>
nnoremap [q :cprevious<CR>
(Some people prefer to run their unit tests with make, I haven’t found a good
way to get trial results into the quickfix window yet.)
Or to move the current line up and down (from normal, visual or insert mode) one line at a time with “Ctrl-Shift-Up” and “Ctrl-Shift-Down”:
nnoremap <silent> <C-S-Up> :move .-2<CR>|
nnoremap <silent> <C-S-Down> :move .+1<CR>|
vnoremap <silent> <C-S-Up> :move '<-2<CR>gv|
vnoremap <silent> <C-S-Down> :move '>+1<CR>gv|
inoremap <silent> <C-S-Up> <C-o>:move .-2<CR>|
inoremap <silent> <C-S-Down> <C-o>:move .+1<CR>|
Or ack (with ack.vim) the word under the cursor (or the current
visual selection), and put the results in the location list, with
<Leader>gw or <Leader>gW:
" :LAck the word under the cursor in the current file and open the location list.
nnoremap <Leader>gw :silent LAck \\b<C-r><C-w>\\b %:p<Bar>:lwindow<CR>
vnoremap <Leader>gw "zy:silent LAck <C-r>z %:p<Bar>:lwindow<CR>
" :LAck the word under the cursor recursively and open the location list.
nnoremap <Leader>gW :silent LAck \\b<C-r><C-w>\\b<Bar>:lwindow<CR>
vnoremap <Leader>gW "zy:silent LAck <C-r>z<Bar>:lwindow<CR>
" Location list navigation.
nnoremap ]w :lnext<CR>
nnoremap [w :lprevious<CR>
(It is possible to change :LAck to :lgrep with no or few modifications.)
Macros, or complex repeats, are closely related to mappings but seem to be geared more for short-term use. The Vim wiki page for macros talks about saving macros but I would turn it into a mapping for longer-term use.
Begin recording a macro by pressing q followed by the name of
a register, the text “recording” will appear in the status line to confirm,
commands are recorded into the selected register until q is pressed again. To
execute (read: play back) the contents of a register use the @ command
followed by the name of the register to play back. Usefully, @@ will execute
the previously executed macro again.
Recently I ran JSHint over a codebase I work on and it suggested, among other
things, I rewrite foo["bar"] as foo.bar. Now this may seem like a job for
a substitution but consider these points:
This only applies to indexing objects with static strings, which could
potentially be delimited by ' or ", and contain escaped delimiters.
These statements often share a line with other code that I don’t want to unwittingly break.
I already know Vim commands and I can build my macro as I edit with powerful text-editing commands.
Using my JSHint compiler and ]q the cursor is placed on the first character
after the [, armed with this I arrived at the following sequence of commands
after only a few attempts:
di'"_ca[.<Ctrl-R>"<Escape>
(<Ctrl-R> and <Escape> are literal keystrokes pushed during the recording.)
Delete the text inside, but excluding, the single quotes (di'). Delete the
text inside, and including, the square brackets into the blackhole register and
start insert mode ("_ca[). In insert mode, insert a period and the
contents of the unnamed register, containing the text from the first delete,
and return to normal mode (.<Ctrl-R>"<Escape>).
Pressing ]q to move between errors and @@ to run my macro over them
(occasionally making other edits) really sped the process up while also giving
me a warm fuzzy feeling inside.
Mappings and macros are powerful ways to improve productivity with tasks you perform frequently, the difficult part is recognizing those time-consuming (or RSI-inducing) bad habits that would benefit from being converted to mappings (or macros.)
I’m slowly building up my collection of mappings, most of which were inspired by the work of others, but I’d love to hear about some mappings you are proud of, rely on day to day or just think are awesome!
I don’t have a topic planned for my next post, if you have something you’d like to know more about or something interesting you think other people should know more about, let me know!
There is a timeout for mapped key sequences, see timeout, ttimeout, timeoutlen and ttimeoutlen for more information. ↩
To use Pyflakes as your “compiler” for Python files in Vim put this into ~/.vim/compilers/pyflakes.vim 1:
CompilerSet errorformat=%f:%l:\ %m
CompilerSet makeprg=pyflakes
Then you can do :compiler pyflakes to set the compiler (although you might want to do that in an ftplugin) and :make % to run the current file through Pyflakes and put any errors into your Vim quickfix window.
This assumes that “pyflakes” is an executable in your path that runs Pyflakes, adjust makeprg accordingly. ↩
If you’ve used the Internets and a browser (I found you!) then you’ve probably also typed a bunch of text into a <textarea> element and thought “Meh.”
Enter It’s All Text. Executive summary: Edit <textarea>’s with your favourite editor and enjoy a healthier lifestyle. It’ll even update the text area for you when you save the document in your editor!
Hundreds of syntax files exist for almost every good text editor, like Vim:
:set ft=tracwiki:set ft=mail:set ft=markdown:set ft=WikipediaGot any others suitable for the Interweb? Tell me.
This is the second part in the series Taming Vim, a series focused on improving the intermediate Vim user’s understanding and operation of the text editor.
Vim features an amazing amount of functionality at its core, functionality built up over the years (Vim itself is 20 years old this year and Vi, in the incarnation we know today, was created more than 30 years ago!) The beauty of Vim’s design is the “language” (see Jim Dennis’ exquisite answer linked from my first post) used to communicate your intentions to the editor.
For example, by introducing only a new motion you can now select, compose or otherwise operate on a new “shape” 1 of text with the same verbs you’re already familiar with.
There are hundreds of official plugins for Vim, and probably hundreds more unofficial plugins, these are some of the plugins I use and am familiar with with, it is by no means a complete list. I encourage you to explore the Vim plugins available through official and unofficial channels.
I recommend using Pathogen to automatically load your plugins while keeping
them in separate directories for ease of management, it has the added bonus of
being able to generate help tags for all plugins with the :Helptags command.
Vim text objects provide a convenient way to select and operate
on the shape of text. In a language like Python it can be useful to operate
on text in your current level of indentation, enter indent-object. For example,
assume that ▯ is the cursor in normal mode:
if cond:
foo()
for x in xs:
▯bar(x)
From this line pressing <ai will unindent the entire loop, including the
for line by one level. From the same line pressing <ii will unindent only
the loop body.
:h indent-object
Simply put, Tabular aligns a body of text on a pattern; for example, lining up your assignment statements, which is a grueling task when done by hand. Drew Neil covers this plugin in one of his excellent screencasts, well worth watching.
:h tabular
This powerful plugin is all about things that surround other things:
parentheses, brackets, quotes, XML tags, etc. For example, assume again that
▯ is the cursor in normal mode:
Hello ▯world.
Pressing yss" will wrap the whole line (you can use any motion instead of
the final s here), excluding leading whitespace, in double-quotes:
"Hello ▯world."
Pressing cs"' will change the surrounding double-quotes to single-quotes:
'Hello ▯world.'
Pressing cs') will change the surrounding single-quotes to parentheses
without padding (use ( for inner-padding):
(Hello ▯world.)
Finally, pressing ds) will delete the surrounding parentheses:
Hello ▯world.
This really just scratches the surface of surround.vim, something I didn’t cover is using it when writing an SGML-based language, like XML or HTML.
:h surround
Vim’s undo feature may look like any normal linear undo history, u to undo
and Ctrl-r to redo. Actually it’s a tree! When you modify an
older text state, i.e. pressing u a few times and then changing the buffer,
you are creating a new undo branch. Pressing u or Ctrl-r moves you backward
or forward chronologically along your current branch, g+ and g-
traverse the entire tree in chronological order. You can even go back and
forward by a relative amount of time with :earlier and
:later:, use :earlier 5m to go back to a state from 5 minutes ago!
Time travel!
It can be tricky to visualize this undo tree, which is where Gundo comes in, it draws a pretty ASCII tree showing you the current undo tree and will let you move around it easily.
Drew Neil explains it with pretty diagrams and Back to the Future references.
:h gundo.txt
Managing buffers can be an arduous process, inevitably when working on a large project you’ll either have a million hidden buffers or a million tabs open (and probably still have hidden buffers.) LustyExplorer can search your buffers by name (with fuzzy matching) and can grep the contents of your buffers to find that other buffer with that text that said that thing in it. Hello productivity!
As well as being a buffer manager, LustyExplorer is a great filesystem explorer
that’ll let you search your filesystem, again with fuzzy matching, from either
the current working directory or the directory of the current file. Once you’ve
narrowed your search down you can press <Enter> or <Tab> to open the file
in the current window, or Ctrl-t, Ctrl-o, Ctrl-v to open the file in a
new tab, horizontal split or vertical split, respectively.
Unfortunately the only complete documentation exists as a comment within the plugin source itself.
If you’ve ever used snippets in applications like TextMate or Visual Studio then you’ve used snipMate. With a comprehensive list of snippets for popular languages, using a snippet is as simple as typing the keyword and hitting tab:
cl<tab>
Produces:
class ClassName(object):
"""docstring for ClassName"""
def __init__(self, arg):
super(ClassName, self).__init__()
self.arg = arg
Pressing tab again moves your cursor between the snippet placeholders. You can define your own snippets too which is extremely useful for repetitive tasks such as laying out unit test skeletons.
:h snipMate.txt
Plugins are a great way to make big improvements with a little action but don’t rely on gimmicks for Real Ultimate Power, exploit Vim’s core strengths and rely on plugins to reinforce the weak areas. Don’t be the person whose Vim session has ten information-panels, a multi-line toolbar and only a 40x25 window for entering text.
In the next installment I’ll talk about keyboard mappings and touch on Vim macros.
(Writing text is fun and imagining I’m helping people makes me feel warm and fuzzy but it leaves me feeling a little detached. I’ve decided to ask the Internets a question at the end of each post that can be answered in a tweet, both to educate me and other people. If you enjoyed this article or learned something I’d appreciate it if you participated, consider it a knowledge donation!)
Tweet me your one Vim plugin you’re most grateful for, especially if you wrote it yourself.
By “shape” I mean the external characteristics that separate, for example, words from sentences, sentences from paragraphs, individual words from quoted phrases, etc. Vim often refers to these as “objects” or “text objects” which I find a slightly dull term. ↩
This is the first part in the series Taming Vim, a series focused on improving the intermediate Vim user’s understanding and operation of the text editor.
Firstly, I’d like to thank all the people who put their .vimrc on the Internet, with comments for everyone else to learn from, these have been incredibly helpful. I’d also like to thank Piet Delport for being patient with me and encouraging me to learn, Tristan Seligmann for introducing me to Vim many years ago, and JP Viljoen for suggesting I write this.
Secondly, I feel it is important to state that my primary use for Vim is writing source code. Today source code is still text and many concepts apply equally as well to prose as they do to source code, if not better, so while not everything in this series may be relevant to prose there are still some general concepts that can improve programmers and writers alike.
Finally, I write this as someone who, until recently, was generally frustrated with Vim and, to some extent, my own inability to adequately wield some of the power of this editor. I write this in an attempt to help the people who feel the same way.
Obvious as it may be, you’ll want to mentally steel yourself for the fact that you will be doing a lot of reading in the process of widening your Vim knowledge. Following on from that, it is important to habitually consult :help (:h for short since you’ll be typing it a lot) for any options or commands you encounter, especially if you think you already know what they do.
Jim Dennis’ extremely comprehensive answer explaining the “Zen” of Vi is a great read, read it. If you find yourself doing something repetitive or lengthy (like deleting the text inside of quotes the long way) it’s extremely likely that you can apply Jim’s advice to greatly improve your productivity.
My own .vimrc is available on Launchpad, along with my .vim directory.
While the attractiveness of something’s appearance is a deeply subjective topic, I cannot stress enough the importance of finding a color scheme that allows you to comfortably read large bodies of text for extended periods of time. Be wary of beautiful bright and colorful schemes like Monokai for these may be the cause of eye fatigue.
I’ve recently switched to Solarized, as a programmer there is something comforting about a color scheme based on practical facts. I suggest enabling the highest contrast mode for Solarized by adding let g:solarized_contrast='high' (before the colorscheme command) to your .vimrc.
There are many Vim color schemes to try on the Internet, Google is your friend.
Like color schemes, fonts are deeply subjective and you should carefully weigh your own tastes against anyone else’s opinion. I use Monaco (sans anti-aliasing) on my Mac and Consolas on my Windows machine, Dan Benjamin has a good write up and there are also about 31 million other things on the Internet about programming fonts.
I find it convenient to use a font size big enough to be comfortable to read even beyond normal typing distance but also small enough such that a vertical split, of a maximized OS window, leaves me with two windows at least 80 columns wide.
Take your time deciding on a color scheme and font that feels comfortable (and attractive) to you. I encourage you to stray from the defaults and suggest trying a change for at least an hour before making a decision.
In the next installment I’ll talk about some Vim plugins and why they’re worth using.
To use JSHint as your “compiler” for Javascript files in Vim put this into ~/.vim/compilers/jshint.vim 1:
CompilerSet errorformat=%-P[jshint]\ Error(s)\ in\ %f:,%E%m.\ (line:\ %l\\,\ character:\ %c),%C%s%>,%Z
CompilerSet makeprg=jshint
Then you can do :compiler jshint to set the compiler (although you might want to do that in an ftplugin) and :make % to run the current file through JSHint and put any errors into your Vim quickfix window.
Update: If using node-jshint then the error format is a little simpler:
CompilerSet errorformat=%f:\ line\ %l\\,\ col\ %c\\,\ %m
This assumes that “jshint” is an executable in your path that runs JSHint, adjust makeprg accordingly. ↩
Are the default PuTTY colors offending your sensibilities? Wish there was an easier way to apply a new theme than manually twiddling numbers or applying registry files and copying the changes to your existing PuTTY profiles?
Me too.
Which is why I wrote a script to read an iTerm (or iTerm2) color file (.itermcolors) and import those colors to a PuTTY profile of your choice!
Available from my Launchpad branch.
Head over to the iTerm2 gallery or Solarized page to get started.
GidoGeek: How to make iCal play nice with Sparrow -
It’s no secret I love Sparrow. I’ve been using it since it was in beta and I’m a very happy customer.
Abandoning Apple Mail for a third party e-mail application however does come with it’s quirks. Apple was nice enough to not respect the “Default e-mail reader” setting (which is in Apple Mail…
“In 1872 the Australians invented the condom, using a sheep’s bladder. However, in 1873 the English somewhat refined the idea by taking the bladder out of the sheep first.” — @froztbyte