Why not put a git repo of your .vim/ somewhere publicly accessible, then just check it out wherever you need to use it? Going further, just have a simple to remember repo address with all your dotfiles... or even just an init script that bootstraps your environment for you? A good custom environment, catering to your preferences can help a lot. It is a bit of a pain to initially set up, but then it's just a command or two at first login, and you have your environment everywhere.
I've thought about it, but in the context of, "I'm reformatting this disk, and I need to back up my home directory to have after I'm done," since I would cry many tears if I hosed my ~. But in that case, I just make a copy of it somewhere instead of putting it in git, or whatever. Putting it under version control for more casual reasons, though, sounds like a good idea. Plus, you get revision history! I might just do that. :)
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 like to think of it as maximizing the following equation. How fast is my main vim going to be * percent of my vim editing time vs. how fast a one off system is * performance penalty for sometimes trying the functions that you have in the main system * the percentage time spent editing in that system.
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.
Oh, I agree fully. Optimize for the common case. This is why I make a few exceptions like Ctrl-P.
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.
In my experience, as long as I don't customize the regular keymappings, switching to a vanilla vim is annoying, but not crippling. About a minute of "dammit I can't use bufexplorer or :Ack" and I'm on my way. A large number of my vim keymaps are programming language specific, so this reduces the level of annoyance even further, as I won't be editing a lot of code on a "burning" server, mostly config files. Any code that is changed, will be a bit annoying, but the changes are usually not big enough that it requires a ton of fancy editor-fu anyway.
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 :) )
Not many plugins make it an unfamiliar editor. Actually, reconfigurations of core vim are more likely to cause that kind of frustration (e.g. if you change vim to use Ctrl-V for paste instead of blockwise visual mode). This is so easy to fix.
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.
I keep my dotfiles under source control because my needs on linux servers and personal OSX machines sometimes differs quite a bit, being able to branch my zshrc is just plain awesome.
This will be one of my few exceptions to a stock system. This plugin will certainly increase productivity given that I spend the majority of my time in Vim 7.
This is a great idea if you are always running on a modern system. I learned Vi (and later vim) out of necessity because I was programming on Solaris 9 and USS (unix on z/os) and modern Vim was just not available.
