Buffers, Windows, Tab Pages

Every buffer created in Vim, at startup or later, is added to the buffer list where it is assigned a number that will never change until the buffer is explicitly wiped out from the list.

Beside that number, buffers are also named after the file they are associated with, if applicable. This gives us two ways to address a buffer:

A typical Vim session could consist of editing a single file—​and thus a single buffer—​or it could go on for weeks and consist of dozens and dozens of buffers. Keeping track of a potentially large number of buffers would be daunting if Vim didn’t gave us not one, not two, but three commands for listing buffers:

All those commands do the same thing so we will simply use the shortest: :ls. Here is what its output looks like:

But we have no cursor, no active line, no selection…​ Obviously, this list is not nicely interactive so what good is it? Well, the last line gives us a hint: pressing ENTER unsurprisingly makes the list go away but we can also press : to enter command-line mode and use an Ex command to do something with the info we get from the list.

Because of their central role, buffers come with many navigation and management commands, let’s see a few things we can do with the list above:

Unlike “modern” editors, Vim can’t display a permanent list of loaded buffers by default. This may feel like a limitation if you are used to that feature but think about it for a moment…​ do you really need that list when you are not trying to jump to another buffer?

To sum it up, the most basic way to switch to another specific buffer is a two steps process:

Of course, it is not necessary to do :ls before doing :b24 but who wants to actively maintain a list of buffers in his head? Well…​ I certainly don’t.

One way to avoid thinking too much about your buffers would be to mash :bn[ext] and :bp[revious] until you get where you want. Because the buffer list is one-dimensional, you are sure to eventually get to the right buffer but cycling is not really a silver bullet when your destination is sixteen buffers away. There must be a more deterministic solution.

Let’s go back to that boring :ls, then <CR>, then :b24, then <CR> routine which looks like a good candidate for a nice, mnemonic, custom mapping. Flying is faster than cycling, right?

Following the pattern we established earlier, we could add something like this to our vimrc:

which seems to work perfectly:

But there’s something fishy with that mapping: it certainly is easy to remember, easy to type, and easy to think about…​ but it doesn’t really behave like its friend <leader>f. Hmm…​ let’s try something different.

Vim is rather famous for the way its normal mode commands span the entire keyboard but there are a few gaps, here and there, that we can take to our advantage.

One of those gaps can be found in how operators work. Operators are normal mode commands that don’t do anything by themselves; they wait for us to tell them on what to operate. c, for example, is an operator, just like y or d, that expects a text-object or motion. If we don’t provide one, operators will keep waiting until we decide to give them a purpose. As an example, here is the command for “changing from the cursor to the end of the current word”:

Now, Vim comes with a bunch of motions like e, but not all keys are associated with a motion. As it turns out, we can associate unused keys with c to create a many normal mode combos that don’t do anything:

And the same can be done with other operators:

There’s another—​slightly smaller—​gap: “commands starting with g” and “commands starting with z”. Even if they work differently, those two-characters commands look a lot like the operator-based commands above and the missing pairs can be used in the same way:

Hmm…​ gb sounds a lot like “goto buffer”, doesn’t it? Here we go:

Now, pressing gb in normal mode opens the buffer list like :ls and populates the prompt with :b, ready for us to perform an operation on one or more listed buffers:

Not bad at all, and that’s one more mapping to add to our vimrc.

But there’s one problem with numbers: the file-to-number relationship is not very intuitive. We Humans are naturally better at names than numbers so the second way to address buffers, names, may have a lot of potential here.

Well, it happens that the buffer commands we used before, :b and :bd, can take a buffer name (even partial) as argument so switching to a buffer, especially with tab-completion and the wildmenu, can be very close to friction-less:

Again, we can easily create a convenient mapping to save a bunch of keystrokes:

The similarity with the <leader>f mapping we added to our vimrc in the previous chapter and the <leader>e mapping it replaced is not a happy coincidence. We have two commands with a similar purpose—​navigation—​that work exactly the same way and follow the same naming convention:

With <leader>f and now <leader>b we have the beginning of a collection of easy-to-remember and consistant navigation mappings—​exactly the kind of mapping we need—​as well as another one, gb, which simply demonstrates another way to approach the same problem.

We shouldn’t be concerned with buffers only for navigation, of course: Vim allows us to perform actions on each buffer in the buffer list with the :bufdo command:

:bufdo can be used to perform an identical edit on every listed buffer, set a local option or do whatever complex thing we need.

By the way, did you notice that Vim doesn’t ask us to write each buffer before changing to another one? That’s because of the hidden option we enabled at the start of our journey. With nohidden, the default value, juggling with buffers would be a lot less fun.

Splitting the current window in two side-by-side views is done with either <C-w>v--all window-related commands start with <C-w>--or :vsplit (shortened to :vs).

Splitting the current window in two windows one above the other is done with either <C-w>s or :split (shortened to :sp).

By default, the splitting is done above and to the left of the current window. This can be very counter-intuitive but that behavior is easily changed by prepending :vs or :sp with :bel[owright]:

or—​more constructively—​by adding those two options to your vimrc:

The funny thing with window-splitting, though, is that the vocabulary is a bit counter-intuitive. :vsplit, for example, splits the current window along the horizontal axis to obtain vertical windows and :split does its splitting along the vertical axis to obtain horizontal windows.

OK. Maybe I’m the only one finding that “funny”.

:vs and :sp can be used with or without argument. When given an argument, they do their usual splitting and edit the given file in the new window. Basically, :vs file2 is the same as :vs followed by :e file2.

If buffers and windows had a one-to-one relationship, listing windows would make just as much sense as listing buffers for navigation purpose but there is no such relationship and no built-in method to address a window by its name.

Moving the cursor to another window usually involves the <C-w> prefix, followed by a letter indicating the direction or destination:

Then comes my favorite window-related command:

which makes alterning between two windows a breeze. Just like with <C-^> for buffers.

Sometimes, building the perfect layout means moving windows around:

or resizing them:

But, to be perfectly honest, I rarely have multiple windows and, when I do, I prefer to use my mouse/trackpad to resize them. YMMV.

Here is a last command to wrap up the subject:

You can close the current window with :q or <C-w>q.

You can close every window with :qa.

If Vim complains about unsaved buffers but you don’t care about losing your changes, you can use :q! and :qa!.

Creating a tab page is easy:

The commands above can’t be easily shortened so one could very well create custom mappings along the same line as the ones we created earlier:

Closing a tab page is just as easy:

Note that closing a tab page also closes its windows but it doesn’t delete the buffers currently displayed in those windows. Remember : windows are views and tab pages are assemblages of windows.

Switching to another tab page is also well covered and pretty intuitive:

In normal mode, gt is the equivalent of :tabnext and gT is the equivalent of :tabprevious.

Here are a few example usages:

Like with buffers and windows, it is also possible to execute a command in each tab page: :tabdo command: