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

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.

Anyway, that said, Ctrl-P makes the cut. :)

Either way, I don't think I'd go much further from stock than I already do because like shortlived illustrates, there's just sometimes you have to use the vanilla version of whatever you're dealing with, no matter what you do.

I find that the most time is spent for me in my main vim session on my computer and the ancillary servers do not need the more advanced text editing features because I am just not in them that often.

But in this situation, there's one variable missing: the urgency with which off system editing happens. If a machine is blow'd up and stuck in single-user mode, and the only way to get it back is a heroic vi session, or if somebody screwed up an apache config and your site is bouncing customers, or whatever, those are the times you don't need the added frustration of an unfamiliar editor.

That, and I didn't find stock vim to be uncomfortable once I learned it, so I don't feel like I'm sacrificing much to get the luxury of my editor working pretty much the same everywhere in the universe.

The biggest thing I have found with all of this tho, is that everyone has different prefs, so if you're pretty happy with the way it's working, don't change because some folks on the internet are suggesting it, but if sounds interesting, give it a try, the worst that happens is you have to revert to the old way. (different optimization problem here I guess :) )

Getting your dotfiles in git once didn't seem necessary to me - and indeed you can get by just fine - but god it is nice not to have to redo any configs and have my setup always ratcheting forward because I don't keep losing things or not having them.

It might make sense for a consultant admin who is managing dozens of systems and 100's of boxes. But for a developer not crafting and utilizing the best tool chain possible is just a waste.

As a heavy plugin user who routinely connects to machines without the plugins, it is not an issue for me at all. And I learned vim while using tons of plugins. But obviously if you are depending heavily on something like Cream (which makes its behavior more like gedit or something, insert mode all the time) you are going to have a tough time adjusting. Very few plugins change vim's behavior in that kind of fundamental way, however.

Life is short. Use the plugins you want to use.

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.

Send praise to https://github.com/kien!

Is also quite good.

It would cool to have a performance comparison

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.

https://gist.github.com/ee14d6ecb9196a07da56

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?

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

    cd
    vim
    <Ctrl+P>
    (wait 10~15s for it to complete)
    <ESC>
    :q
    find . |wc -l
    183239

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

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.

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.

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>

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

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

    nmap <c-h> :FufHelp<CR>

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

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

Will this automatically update its cache as new files are added?

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

    brew install macvim --override-system-vim

* 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)

Ctrl-P is the recommended find plugin from the janus vim distribution: https://github.com/carlhuda/janus I use most of the other plugins from there and will be trying out the others.

Thanks to kien for making it!

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

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.

I'm so sorry :P

In all seriousness, this looks like a good contender to Command-T judging by a cursory glance through the README. I'll have to give it a shot.

So yeah I am not an expert. If I learn it, maybe it'll be better. It's a tool thing though. Vimscript isn't a very good tool compared to the other ones that exist now. I mean, doesn't Vim support other languages now? Why don't people use them at this point?

But probably the #1 reason to write a plugin in it is that your users don't have to run some flaky Makefile/Rakefile or install system dependencies in order to use your plugin.

This is most of the reason I jumped ship from Command-T to Ctrl-P as soon as it came out.

I will concede that Vimscript looks grody and I wouldn't write non-editor software in it, but it is really a DSL for configuring an editor on the fly, works great for that and doesn't really hold a huge number of shocks for someone who can handle things in the range of C, bash, etc.

I found this in the help docs.