96 comments

[ 29.6 ms ] story [ 470 ms ] thread
I can attest this is awesome and works awesome.
Ctrl-P does something that I wanted Command-T to do for a long, long time: if you invoke it and select a file that is already open in an existing window somewhere, rather than open a new window for that file, it will switch to the already-opened one.

You can change how this works, too: look up ctrlp_switch_buffer in the docs.

Also, it can sort by MRU and switch mode (Ctrl-B/F) while its window is shown. And mark multiple files.
Awesome, I'll have to take a look at how that works. I've gotten it to work with quickfix (set switchbuf=useopen), but still have no idea how to get vim to do that for ctags.
Does Command-T ever open new windows? For me it opens the file in the current window, and if the file is already open in a buffer, that buffer gets shown in the current window.
You're right, unless you C-s or C-v it into a split (which I do pretty often).

When I was first migrating from TextMate, the default behavior seemed like a bug. Why would you routinely want to open a buffer in two different windows? Why wouldn't you want the editor to find your already-opened file in the labyrinth of splits and tabs you've opened?

Now, partially due to this behavior, I tend to see large lattices of open windows and tabs and splits as a sign that I'm getting unfocused, and try to be better about closing splits as soon as I don't need them, and avoid tabs altogether.

That splits should be transient seems more vim-like.

https://github.com/wincent/Command-T

Is also quite good.

It would cool to have a performance comparison

The main thing that attracted me to Ctrl-p was that it is written in pure vimscript. Command-T, however, requires your vim to be compiled with Ruby support.
I was never able to get Command-T to work. CtrlP works out of the box without extra work.
I'm also interested in knowing how fast this is with huge directory trees.

I remember in early versions of Command-T, the Ruby implementation was slow for big trees. They rewrote some of it later in C.

I just overheard Wincent say that Command-T was always written in C because previous Ruby plugins that attempted to accomplish the same thing was too slow. Command-T was written to be instant.
FWIW I ran

    cd
    vim
    <Ctrl+P>
    (wait 10~15s for it to complete)
    <ESC>
    :q
    find . |wc -l
    183239
Fast enough for me. (MacBookPro5,5 + aftermarket Samsung 470 SSD)

Command-T is faster for sure. But it lacks critical features that Ctrl-P has (no vim -ruby dependency for one).

When you start vim again and hit ctrl+p, does it do all that over again?
If I don't quit vim, and do Ctrl+P, things got cached (which you force-refresh with F5) so it's instant.

If I quit and restart vim, the Ctrl-P cache is invalidated thus it's scanning again, but it's down to 3~5s since disk reads got cached by the OS.

Yes. But you can specify a local cache file if you want... in which case it would not start over when you restart.
Ah, I see. I added a similar feature to Command-T, because scanning one of my projects trees takes a couple seconds.
As a quick and dirty test I tried running both Command-T and Ctrl-P against a directory tree containing some 26,000 XML files. Command-T takes roughly 10-15 seconds to become responsive. Ctrl-P chokes and requires a Vim restart after invoking it against this directory.
That should be a fairly trivial fix in both of them.

Simply abort the scanning after a configurable threshold (either seconds or files).

Needless to say that, yes, this must be implemented.

I've choked my vim more than once by accidentally running Command-T or FuzzyFinder in the "wrong" directory. That should not happen.

Command-T definitely has the feature you're talking about (CommandTMaxFiles I think.) I'm not sure about CtrlP.
If you are on Unix, add this to your vimrc and the directory indexing speed should go through the roof:

https://gist.github.com/ee14d6ecb9196a07da56

Is that offloading the task of scanning file names to the find command?
Looks like find is piped into head, though. So it would only index the first ten?
No, it's the first g:ctrlp_max_files which is defined as 10000
Oh, true. Good call.
Is there a reason that Ctrl-P, FuzzyFinder, and Command-T choke on large directories? On windows, I've used this piece of software called Everything Search that seems to index the entire filesystem (say around 30,000 files) in under 5 seconds. That's really impressive and I love using it for that.

But it makes me sad to use these vim extensions choking on directories of similar size. Maybe NTFS vs ext4 has something to do with it?

The overall comparison ends up being: Command-T is more of a pain to get setup, but is faster. CtrlP is easier to get setup, but is slower.
In the projects I have worked on, Ctrl-P seems faster than Command-T, but it's matching results are far from a replacement for Command-T. Ctrl-P often will not find files even when I type out the full file name. Command-T's match results are great. Ctrl-P will also show results from hidden/ignored directories. When Ctrl-P is smarter about its match results, I will use it more frequently.
Awesome to not have to compile this with (SYSTEM!) ruby.
I was using PeepOpen which is quite nice, but (of course) it doesn't work in the terminal. This looks quite spiffy.
Very Awesome! Commmand-T (vim plugin) has been an essental part of my workflow for years now. I can't live without it. The biggest thorn for setting up a new host is having to procure VIM with Ruby support. Thank you so much for doing this!
It seems fast enough to use on mozilla-central (the Firefox repo), which is huge.

I can't find some files, though. If I type :

ctrp+p, mediaelement, it should find content/html/content/src/nsHTMLMediaElement.cpp, and it does not. I tried to set the maximum depth, but it didn't work. In fact, it does not match content/html/content files.

Another thing that I find annoying, is that when I remove multiple characters, it does its matching thing again, and because I type the backspace pretty fast, it kind of locks up for a second or so.

Anyway, other the couple quirks mentionned, excellent plugin, works out of the box.

There seems to be a bug when in full path fuzzy mode. In the CtrlP window, hit ctrl-d (match file name only) and see if it works.
In addition to max depth there is also a max files setting to adjust.
I have this installed as it comes with Janus (https://github.com/carlhuda/janus), and it's excellent. I tried to get Command-T to work in the past and failed, but this works with no problems, and is incredibly useful.
If you're on Ubuntu and do not want to build vim with Ruby support, but still want to use Command-T for some reason, install vim-nox.

That being said, ctrlp is less of a headache since it's pure vimscript like the headline says.

Similar to vim-nox, if you're on a Mac, you can install MacVim with homebrew like so:

    brew install macvim --override-system-vim
which creates a /usr/local/bin/vim symlink, spawning a real terminal vim, not a GUI MacVim. And contrary to /usr/bin/vim this one will be built with the (system-provided) python and ruby support.
What's the easiest way to install this? I have pathogen if that makes any difference...
Tangential, but you might like vundle (if we're looking at replacement plugins already) instead of pathogen.
Agreed, I was a pathogen devotee until I tried vundle. Never going back.
Another vote for vundle. Not having to manage git submodules is a nice change from pathogen.
Does anyone know how to change default search behavior from full-path to filename? I read the help but don't see the option...
Ctrl-D will switch between path and file modes.
Sorry, I meant, in your vimrc file.. Having to hit ctrl-d each time is a PITA.
let g:ctrlp_by_filename = 1

I found this in the help docs.

Love this plugin, makes vimming so much nicer and is my favorite file/buffer manager. I like you you can optionally keep the cache so when you reopen there isn't that delay for checking the directory tree too. let g:ctrlp_clear_cache_on_exit=0

Thanks to kien for making it!

Great plugin. I love that it tracks up to the nearest .git etc folder to decide where to search from. That's a killer feature.
Anybody have an opinion on ctrlp vs LustyExplorer? http://www.vim.org/scripts/script.php?script_id=1890
I've used LustyExplorer for one year before switching to CtrlP about 2 or 3 months ago. In my experience:

* speed is comparable * quality of results is better in LustyExplorer * interface design is better, more Vim-like and more consistent in CtrlP * CtrlP doesn't need Ruby * CtrP is more extensible and already integrates a tight pack of useful features (MRU, grep, tags)

How does this compare to FuzzyFinder? FuF has been far better than other options people espouse like Command-T but still has some warts of its own.
Is there a way to easily open a file into a split?
ctrl-v opens it in a vertical split.
(comment deleted)
Thanks for posting this!

I've been a longtime FuzzyFinder and Command-T user but both have pretty nasty warts. Crossing my fingers that this will finally be the one to do it right.

Can somebody please point out the differences with a customized FuzzyFinder?

As I have it I get fuzzy completion from the root folder, opening splits with <c-j> and <c-k>, opening tabs with the file with <c-l>, deleting buffers from the list with <c-]>, and such.

Is there any difference or improvement one should try? Genuine question, I am really curious. It would be great to see a comparative between FuzzyFinder, Command-T and Ctrl-P...

ps: fuzz config is like this in vimrc:

    " Fuzzy Finder
    nnoremap <leader>fr :FufRenewCache<CR>
    nnoremap <leader>ff :FufFile **/<CR>
    nnoremap <leader>ff :FufFile **/<CR>
    nnoremap <leader>fg ye :FufFile **/<C-r>"<CR>
    vnoremap <leader>fg y :FufFile **/<C-r>"<CR>
    nnoremap <leader>fb :FufBuffer<CR>
    nnoremap <leader>fd :FufDirWithCurrentBufferDir<CR>
    nnoremap <leader>fl :FufLine<CR>
(Ignore the maps, thats how I like it)

Edit: I would like to point out that I have skimmed several times through the docs of Fuzzy Finder and there are several options I dont even use/grasp, so more knowledge and tips on Fuzzy Finder would be appreciated also

I've used fuzzy finder and it's ok, CTRL-P gives me a faster experience so give it a go.
I use Fuzzy Finder in concert with Command-T: Command-T for quickly navigating the current working directory and Fuzzy Finder for navigating from the root like you. I imagine you could use Ctrl-P similarly, though a customized Fuzzy Finder would likely obviate the need for Ctrl-P/Command-T.

One Fuzzy Finder tip. Make sure and map :FufHelp, if you haven't:

    nmap <c-h> :FufHelp<CR>
It allows you to fuzzy find through the help docs. Being able to see closely related help docs through fuzzy matches is a huge boon when it comes to navigating Vim's help.
It was this feature which made me switch full-time to Sublime Text in the end - Command-T was just too slow in comparison so I decided the Vim emulation in Sublime was good enough for the commands I used, which are just the basics really - arguable how much of a speed difference it makes almost but it's too ingrained in muscle memory now! :wq
I've used this plugin since I discovered it. It replaced fuzzy finder for me.

It is MUCH better.

My killer feature: it will automatically avoid opening files in special buffers. I.e. if you ru. It inside the NERDtree window, it won't load there but rather will load the file in the middle buffer.

Other than this it has loads of other things that make it much better.

It's truly a great tool. I installed it yesterday as an alternative to CTRL-T as I didn't want to install ruby system wide.

It will also allow you to quickly move between buffers with CTRL-P then CTRL-B to select buffers.

The readme says MacVim -- anyone know if this will work in GVim?
Yep, it does. I use it daily in plain-old terminal vim on ubuntu, so I don't use it in GVim much, but trying it just now worked fine.
After 2 weeks of using Sublime I just did this:

rm -rf /Applications/Sublime\ Text\ 2.app/

I will never neglect you again VIM. You've been so good to all of us.

it takes a lot of time for the first launch to cache. Is this normal?