i had trouble with CtrlP initialy because the initial load time is too slow. However, this config line fix it for me

  let g:ctrlp_user_command = ['.git', 'cd %s && git ls-files']

It lets CtrlP use git to list files, which is much faster for large project

I've tweaked mine to this, which includes untracked files, but honours your gitignores:

  let g:ctrlp_user_command = ['.git/', 'cd %s && git ls-files --exclude-standard -co']

It was annoying me that I couldn't open files I'd just created with CtrlP, as they wern't yet tracked.

Just tried this out on my setup, and it made a huge difference. A large project that used to take ~1s to load the first time is now pretty much instantaneous.

As others have said CtrlP is slower; but not having the Ruby dependency makes it _far_ less of a headache to install on Windows, should you ever find yourself on such a machine.

Installing command-t is fairly easy on windows. Just compile as instructed with latest ruby 1.9 + devkit and replace gvim.exe with the one specified in this page https://wincent.com/comments/6544.

That's a perfect example of something that is both easy AND a headache. It's not certainly difficult to do, but I don't want to be replacing my gvim executable with one provided by an anonymous forum user just to make one script work. Ignoring the potential security issue, what happens when I want to upgrade vim, or run another script that's similarly "easy" to install on Windows?

I can't speak for other vim users, but I haven't had a lot of luck with distro versions of vim and Ruby/Python extension scripts on Linux either. After fighting with it for a while, I ended up just declaring my .vimrc to be a VimScript-only zone. It sucks losing Gundo and Command-T and a couple other great plugins, but it's done wonders for my sanity, and everything works well on Windows as a bonus.

Well the forum is not actually an anonymous forum, the site owner is creator of command-t plugin. When I encountered crash after installing command-t after upgrading to 7.3 almost 1.5 years ago the first google search led me to that page (now first result is this page http://chrislaco.com/blog/gettimg-command-t-working-on-windo..., even better with instruction).

I also had no problem installing it in Ubuntu/Mint. Just removed vanilla vim and installed vim-gtk and then compiled command-t.

Command-t is actually my only non-vimscript plugin in my plugin list, and it is rightfully so :). I tried to cope with CtrlP, but it feels too slow for me for large collection of files. Also its fuzzy matching is not on par with command-t. I have actually no problem to take this little hassle to install command-t for performance consideration :).

Not quite as easy as installing vanilla vim and dropping my ~/.vim (IIRC it's ~\_vim on windows) in place without touching anything.

easy, but not simple

Or OSX where I can never seem to get vim to build from source (which is the only option for Ruby or even Python integration). I know I've done it in the past but every time I need to I forget the magic I need to do.

Just use MacVim and the bundled mvim.

Open file in MacVim:

    $ mivm file

Open file in Vim:

    $ mvim -v file

ooh if I've understood correctly `alias vim='mvim -v'` solves my problem, thanks!

The vim that ships with 10.8 (and IIRC 10.7, maybe 10.6) has ruby and python linked out of the box, and straight-up

    ./configure --enable-rubyinterp && make

works just fine on my machine.

Or if yours isn't for whatever reason, you could cheat and grab MacVim[0] then symlink `/Applications/MacVim.app/Contents/MacOS/Vim` to `/usr/local/bin/vim` (editing paths as necessary)

[0] https://github.com/b4winckler/macvim

A bunch of people have posted about Ctrl-P being slow but I've never had that problem. Here's my user_command:

    let g:ctrlp_user_command = "find %s -type f | egrep -v '/\.(git|hg|svn)|solr|tmp/' | egrep -v '\.(png|exe|jpg|gif|jar|class|swp|swo|log|gitkep|keepme|so|o)$'"

While the CtrlP window is open, hitting F5 will refresh the list of files and it's really fast. I'm on an SSD but it's still basically instant on every project I code in. I think it must have a slow default which gives people the impression that it's slow. After using both FuzzyFinder and Cmd-T for a long time, CtrlP has been easily the best of the bunch.

If you are concerned about speed, it might be worth adding this line to your vimrc as well. This way, ctrlp will keep its cache (stored by directory), and you only need to rebuild it when you create new files.

  "Keep caches between sessions - f5 to refresh
  let g:ctrlp_clear_cache_on_exit = 0

I prefer the builtin vim facilities. I use two features already built into vim. (1) "*" and "**" (ugh stars are italics markers in this editor, how do you escape them?) works in tab completion for both :ts & :e and (2) the --file-tags argument to exhuberant ctags. Oh and one more, :ts supports regexes.

    :ts *Something*xml<tab> (or /Something.*xml<tab>)  

will do what you expect. As will

    :e **/somewhere/*myfile*.

That said, I'm going to check ctrlp out to see if I'm missing something good. :-)

Agreed. I used to use Command T religiously, but I move machines frequently due to the nature of my work and was spending more time trying to get it and its dependencies working on the variety of machines that I use than I was actually, you know, coding.

Granted, Ctrl-P is much slower than Command-T. Won't deny it. But carefully excluding all .git, virtualenv (for python) and similar folders in my .vimrc, along with making sure I cd into a directory a little closer to my code makes it almost as quick for me. And it just works, which is invaluable in my book.

I use FuzzyFinder instead of CommandT + BufferExplorer.

http://www.vim.org/scripts/script.php?script_id=1984

For the repo I work in, CtrlP takes about 3 seconds to load for the first time; CommandT is instant. CtrlP is nice for smaller projects, though.

I have strange issues with CtrlP, especially files not being found although they would be a clear match.

Are they already open / matched by wildignore?

As ehynds points out, CtrlP won't list files that are already open. You are supposed to access those using the 'quick buffer switch' mode. I've bound that command to my Tab key, so seeing what files are open and switching between them is a snap.

It also renders Buffer Explorer obsolete, if used with buffer search mode.