Navigation in Vim. Part one—vanilla features
In the two-part article series I am going to describe different ways of navigation in Vim. The editor, unlike others, gives you the unique power of fine-grained control in many ways. This is also true for navigation.
The original article first appeared on Selleo blog.
The article just scratches the surface, and I will write mostly about what I have found especially useful, as every Vim user has his own favourite tailor-made toolset or preferable workflow. Still, I hope that even more experienced users of Vim will find something useful in my article. I organized Vim navigation into the following groups:
- Vanilla / built-in features
- Basic navigation
- Searching back and forth
- Jumping back and forth
- File explorer
- Other possibilities
- Nerd tree / Vinegar file explorer
- Fuzzy search
- Ag (search tool)
- Fugitive (Git tree explorer)
- Git gutter
Some of them can work twofold, ‘in file’ and across the files. This was described where needed. Please note that I will not focus on explaining differences between and among:
- Windows, or
as this may confuse some newcomers. In my opinion Vim Tab Madness. Buffers vs Tabs is a good read that explains a number of tricky details. In order to have a good start, let me briefly explain what it means that Vim is a modal editor.
Vim is a modal editor
In a non-modal editor, e.g. Google document, when you press h,
h is added to the document. The same applies to Vim if you are in the insert mode. In normal mode, h moves you one character to the left, it is the same as if you pressed ← in an non-modal editor.
How much time do you reckon artists spend with their paint brushes in contact with the canvas? No doubt it would vary from artist to artist, but I would be surprised if it counted for as much as half of the time painters spend at work. Think of all of the things that painters do besides paint. They study their subject, adjust the lighting, and mix paints into new hues. And when it comes to applying paint to the canvas, who says they have to use brushes? A painter might switch to a palette knife to achieve a different texture or use a cotton swab to touch up the paint that is already been applied.
The painter does not rest with a brush on the canvas. And so it is with Vim. Normal mode is the natural resting state. The clue is in the name, really. Just as painters spend a fraction of their time applying paint, programmers spend a fraction of their time composing code. More time is spent thinking, reading, and navigating from one part of a codebase to another. And when we do want to make a change, who says we have to switch to Insert mode? We can reformat existing code, duplicate it, move it around, or delete it. From Normal mode, we have many tools at our disposal. –Drew Neil in ‘Practical Vim’ (2012)
I strongly recommend this book as it will give you a solid foundation to using Vim effectively.
Vanilla / built-in features
In this part, I will describe briefly how to navigate in Vim using built-in features.
Feel like home with the home row
h, j, k, l, also known as home row allows you to move: left, down, up and right, respectively. Vim is far more powerful; for example, you can move around within the viewport or the visible part of the screen easily. Consider this. I am on the line 24. If I would like to jump to the to the top (line 12), I would press H, as in High. L, or Low moves me to the bottom (line 37). M, as you may have guessed, moves you to the Middle of the screen.
In Word, in order to jump to a next word, you have to press opt →. There is no more precision left, though. On the other hand, in Vim, you can precede almost any command with a count. This way, jumping to the 5th word is as simple as pressing 5 w. Actually, it will move you to the beginning of the 5th word; nothing prevents you from jumping to the end of the word with e.
Do not be afraid of having to count words, there are better ways to avoid this; for example, you can use EasyMotion plug-in. In Vim, the idea is to jump to an approximate place, then, you can move move closer to the destination. If you do not feel like counting words, consider searching back and forth.
Searching back and forth
/, ? keys, gently located under your little finger, allow you to search downward (/) or upward (?) of the document, starting from the place you are in. Let’s say that you would like to jump to a place where awesome is written in the document. Simple! Press / and type awesome. You are moved to the place instantly. Pressing ↩ confirms and pressing Esc cancels the action, moving you back to the place where you had been before.
To find the next / previous occurrence of the word awesome, press n or N respectively.
Searching back and forth is sometimes more useful than counting words, and above all, allows you to search using regular expressions. I would not call it searching on steroids, as most editors may have this feature out of the box. Still, unlike other editors, Vim has a few regex modes with fancy names like
- very magic, or
I am sure that there are more than the three above, but this is outside the scope of this article. Searching by regular expressions deserves an article of its own, so let me just list a few resources that can help you understand the basics:
- Practical Vim by Drew Neil
- Refining search patterns with the command-line window
- Simplifying regular expressions using magic and no-magic
- Vim Regexes
The Practical Vim approach to the subject is, in my opinion, devoided of ‘magickeness’, which is an advantage because magic words may bring about confusion. Fortunately, jumping back and forth, another way of navigation that Vim has under its sleeve, is easier to grasp.
Jumping back and forth
Jumping to the approximate place, I wrote above, works perfectly with f and F — jumping to the next / previous occurrence of a character. It is easier and faster to jump to the next comma, period, or a capital letter than counting words or using /
- Periods, commas or capital letters are easily spotted
- Getting to the destination takes only 2 characters
t and T works in a similar fashion as f and F do, but in the opposite direction. They move you before the next or the previous occurrence of a character. Similarly, you can jump to the next / previous occurrence with ; and ,.
Now, you may start wondering why you would need so many magic commands in Vim to be effective. Drew Neil explained this in Practical Vim that Vim allows you to ‘write at the speed of thought’. Yes, it takes some practice, but with time you will not need to stop and ponder what I can use to get there?. No, it will come naturally and will become a habit, allowing you to write as fast as your thoughts are!
Sometimes, though, you need more time to find a file. No editor would be complete without a file explorer. In Vim this can be achieved with
:E) opens the directory of the active file. You may be surprised when you see that list of files opens in the main window, instead of in the sidebar as in most editors. This works well with split windows. Having splitted window into 4 panes (parts), sidebar with file tree open, would not only clutter the interface but would also make you lose the context.
:e) opens a file at a given path. I tend to use
:e to open files that are a part of the pull request for which I do the code review. I just copy the path from GitHub and paste it as an argument to
:e. I have more possibilities like fuzzy search, but
:e fits better in this particular case.
Vim is much more powerful, giving you even more control options with built-in features.
Here are some built-in features:
- Jumping to a given line with
:10or, 10 G
- Jumping to a given line column with 10 |
- Moving around recorded jumps with ⇥ / ⇧ ⇥
- Moving to the previous / next sentence with ( / )
:grepto move around the entire project
As I mentioned before, I did not intend to cover all basic features in this article. However, the idea was to show you the abundant variety of navigation options Vim provides, and draw your attention to the flexibility of this editor. If I managed to catch your interest and be of some help, I will be more than happy.
Special thanks go to Szymon Kieloch for his technical feedback to this article.