5 Minutes Vim: CtrlP considered harmful

This article was originally posted in barbarianmeetscoding.com. 😊

In this 5 minutes of Vim goodness we'll break the shackles of convention and become slightly more productive when using Vim. Here we go!

Of all the activities you'll perform when coding with Vim (or any other editor), one of the most common ones is the simple act of moving between files. Since this is such a common thing we do in our daily coding using a plugin that allows us to move between files seamlessly is a must-have for all Vim users.

These plugins fall in the category of fuzzy search file finders and they let you go from a workflow that in Vim can resemble:

• The slow typing of a file path using the :edit command
• The slow navigating of the file tree of your project in netrw (:h netrw).

and in other editors a manual search for a file with the mouse, to something that is so straightforward and instantenous as thinking of the name of a file, typing it and jumping right into it.

In VSCode it's called quick open and can be reached with CTRL-P or CMD-P. In other editors it's called Go To File or something similar. In Vim there's a slew of plugins that provide a similar (and often more powerful) functionality: fzf.vim, ctrlP and denite are some of the ones which come to my mind as I type these words.

I personally use fzf and I use it all the time. The first mapping that I added to my vim fzf configuration was this:

nnoremap <C-p> :<C-u>FZF<CR> 

I probably found it somewhere in the docs and it has served me really well over the years. I just type CTRL-P, the name of my destination appears in my head, my fingers materialize it into text, and BOOM! I'm in that file.

All seems fine but when you stop to thing about it... Why use CTRL-P at all for such a common coding task? It forces me to move both of my pinky fingers away from the home row. That doesn't feel really great, does it? The answer is probably tradition and inertia. I can't quite remember which was the first editor to provide this sort of functionality (textmate?), but we've just continued the tradition and used this key binding when there are far better choices.

So instead, in order to perform this super frequent task, we can use the premium space in our keyboard, the home row. And we can rely on the <leader> key so that jumping into fuzzy search is super smooth:

nnoremap <leader>s :<C-u>FZF<CR> 

In my vim config <leader>s is <space>s. Both of these keys are under my hand in resting position so jumping into fuzzy search mode is completely friction free.

But this is just an example. The really important thing is the principle behind it:

• Question everything: When using plugins or copying mappings from other plugin configurations or vimrcs from other users question the mappings and commands, think about how often you use them, and adapt them before you incorporate them in your own config.
• Put frequent tasks in the home row: Take advantage of the <leader> key in combination with the home row keys for frequent coding tasks

Happy fuzzy finding!

Comments

[Zoltan Kochan]

Clickbait title😃 I thought it will be about why using fzf is a bad idea.

For me, <leader>+s is not necessarily a lot easier than ctrl+p. IMHO, <leader>+ would be nicer.

I frequently use <leader>+n, which for me focuses the file in nerdtree. I usually work in a monorepo with many small packages and from there I can find the necessary file easily. That's faster than searching the file by name.

[Jaime González García]

hahaha I meant it in the literal sense but I understand what you mean. :D

Using fzf or something like it is a GREEEAT idea. I think that jumping from not having it to using it dwarves in comparison to which mapping to use to trigger the find file behavior. But I have had problems with my wrists and I find like less I stress them the better.

Awesome! I have the same mapping for exactly the same thing hehe. But I don't rely on it so much. Only if I'm in an unknown codebase. In that case is a great way to explore around.

Thank you for your comment! :D

[Kevin Koltz]

I found it really useful to map escape to CtrlPBuffer in normal mode which makes it quick to jump back recent files or to the last used file with esc then enter. Then map leader space (or space space) to CtrlP for all files which is used less.

[Jaime González García]

Uuu that sounds interesting. Is ESC on your Capslock position?

I might steal something of that :D

[Kevin Koltz]

Yeah, mapping caps lock to escape works really well until you go to use someone else's computer ;).

[Ghost]

I like to keep a lot of files open in my i3 with 3 screens, I'm primitive like that, that's why I love (n)vim and my lightweight XFCE4-terminal :)

By the way, when you have 20+ terminals open, xfce4-terminal eats less RAM than Qterminal and even st!

[Vlastimil Pospichal]

I use <space> for switch into insert mode. A comma is much better as the <leader>.

[Jaime González García]

Cool! Hadn't thought of that :D Sounds like a very pleasant way to go into insert mode.

I don't know about the comma though, I find it hard to reach.

Thanks for your comment! :)

[Vlastimil Pospichal]

I always write a space after the comma. If a comma is followed by another key, it is a command in insert mode.

[Elijah Goh]

I've dropped Ctrl+P altogether and just used this command. Just type and press tab.

:e **/*

Skimmed off some boot time.

[Phil Thompson]

Could you expand on this (haha!)? This is not fuzzy find. If you start typing again omnifunc will disappear. It also takes several seconds to populate. If you work on any decent size project this option does not scale as far as I can tell.

[Elijah Goh]

It depends on what you're searching for. For files I'm unsure of, I'll press tab and let fuzzy finder do the work.

// Not very sure of file name but knowing the extension
:e **/MyUnsureFi*.vue

// Knowing which directory
:e app/controllers/**/my_controll

If you scope down the directory, search will be faster. No plugins required. Asterisk only when necessary, scope down when you know the directory. Fast enough for me at least.

[Eric Ahnell]

I never would have thought to make sure the commands you define don't slow down touch typing, but you're right - this saves small bits of time that add up.