I've been using Vim for three years or so. Apart from the usual bunch of plugins (NERD_tree, snipmate, etc), I have a few scripts I like:
Pretty much everything by Tim Pope - surround.vim, matchit.vim, fugitive, etc.
Fuzzy finder. I don't know how I survived without this until a few months ago. It allows you to enter a search term, and returns fuzzy matches, and you can jump to any of the matches. Things that Fuzzy finder supports include files, buffers, tags, help, etc.
Bufexplorer: One more of my favorites. "\be" brings up a little text file which you can use to manage your buffers. This is similar to Emacs' buffer explorer (C-x C-b). Except since this is also a text buffer, you can use common motions to delete, switch, save buffers, etc. (Another item is minibufexplorer, which shows all the buffers like "tabs". I stopped using this after switching to a more emacs-esque way of keeping buffers open and using only one gvim window").
Bufkill.vim: Is a very useful little tool for me. I use splits a lot, and sometimes killing a buffer closes the split. This small tool has been invaluable. :BD closes the buffer, but keeps the splits in place.
Eclim: You can use Eclim as a frontend for eclipse. I use some fancy eclipse IDEs sometime like CDT, PyDev, Aptana, etc. But eclipse's editor isn't spectacular. Eclim allows me to use vim as the editor and lets eclipse do the heavy lifting - autocomplete, project management etc.
Supertab: Use Tab for all your insert mode completion. Somehow any form of intelligent completion was always very flaky for me with vim. Still, I map this to keyword complete, which is usually pretty helpful.
Remotes: This isn't a plugin, but a native feature. You can use Vim remotes to keep one instance of gvim running and use "gvim --remote" instead of "gvim" to open files inside a single instance, rather than open each file inside a terminal, and close it when you're finished. I found this really helps improve productivity.
I've been using Vim heavily for quite a while now. I almost exclusively open files with Fuzzy Finder (the Text Mate variant). I've never manually managed buffers. I open and close splits frequently, but more or less treat my project as if it were entirely in memory at all times.
So, serious question: What benefit do you get from Bufexplorer, Bufkill, etc? Why should I ever think about buffers?
I use Bufkill and bufexplorer for a very special use case.
I've got $EDITOR set to "gvim --remote --wait" which means that the file is opened in an existing instance of vim. Unlike "gvim --remote" which will return control to the shell the moment the file is opened in gvim, the --wait option forces the command to wait till the file is closed (which is the standard expected behavior for most things like writing git commits, etc).
Now the interesting problem is that I have to kill the buffer rather than quit the editor. so I do a :w and :bd to delete the buffer, which makes sure things go fine on the shell.
Sometimes, if I have opened the file in a split (which is invariably the case), using :BD will ensure that my split isn't closed as well, when the buffer is killed.
Plus, BufExplorer has a very neat little trick which I just discovered recently. Sometimes I can close a buffer and might have to reopen it. So I bring up Bufexplorer and press "u" to undo changes, and I can go reopen any of those buffers.
Regarding use of Vim and Eclipse, the Vrapper project has a good enough emulation of Vi in Eclipse, enough so that I've been able to use it without hitting many limitations in my daily use.
I'm currently using Vrapper, and it's been a year or two since I tried Eclim. But as I recall, it's a question of which is primary.
With Eclim you get all of vim, as you say, but you lose a bit of the native eclipse editor functionality.
With Vrapper you get all of eclipse, and a subset of the core vim commands. It's not vim, but you get to keep all of the features of the native eclipse editor.
http://github.com/ninjagod/etc/tree/master/vim/plugin/
I've been using Vim for three years or so. Apart from the usual bunch of plugins (NERD_tree, snipmate, etc), I have a few scripts I like:
Pretty much everything by Tim Pope - surround.vim, matchit.vim, fugitive, etc.
Fuzzy finder. I don't know how I survived without this until a few months ago. It allows you to enter a search term, and returns fuzzy matches, and you can jump to any of the matches. Things that Fuzzy finder supports include files, buffers, tags, help, etc.
Bufexplorer: One more of my favorites. "\be" brings up a little text file which you can use to manage your buffers. This is similar to Emacs' buffer explorer (C-x C-b). Except since this is also a text buffer, you can use common motions to delete, switch, save buffers, etc. (Another item is minibufexplorer, which shows all the buffers like "tabs". I stopped using this after switching to a more emacs-esque way of keeping buffers open and using only one gvim window").
Bufkill.vim: Is a very useful little tool for me. I use splits a lot, and sometimes killing a buffer closes the split. This small tool has been invaluable. :BD closes the buffer, but keeps the splits in place.
Eclim: You can use Eclim as a frontend for eclipse. I use some fancy eclipse IDEs sometime like CDT, PyDev, Aptana, etc. But eclipse's editor isn't spectacular. Eclim allows me to use vim as the editor and lets eclipse do the heavy lifting - autocomplete, project management etc.
Supertab: Use Tab for all your insert mode completion. Somehow any form of intelligent completion was always very flaky for me with vim. Still, I map this to keyword complete, which is usually pretty helpful.
Remotes: This isn't a plugin, but a native feature. You can use Vim remotes to keep one instance of gvim running and use "gvim --remote" instead of "gvim" to open files inside a single instance, rather than open each file inside a terminal, and close it when you're finished. I found this really helps improve productivity.
I even aliased "vim" and "vi" to map to the remote editor. You can see my tiny workaround for this: http://github.com/ninjagod/etc/blob/master/zshrc#L31
I would recommend you read Peter Krumin's articles on various vim plugins, etc.