>It's important to note the context of this article, and most the responses, which is Vim for developers (or at its most general, Vim for sustained local use).

>It's important to note the context of this article, and most the responses, which is Vim for developers (or at its most general, Vim for sustained local use). The reason I bring this up is that there's a whole other set us use that is often overlooked, which is Vim as a standard tool for sysadmins. >Any system you connect to will have Vi, and probably Vim. This makes it an ideal tool for sysadmins that might need to connect to tens or hundreds of systems to know how to use, and to have a fairly standardized behavior. In those cases, having a customized config can actually be more of a hindrance, because switching from a highly customized local Vim instance to a stock remote Vi/Vim instance can be jarring. That's a great point. I had mentioned something to the same effect, briefly, in the blurb for my vi quickstart tutorial, here: https://gumroad.com/l/vi_quick https://gumroad.com/l/vi_quick I first wrote that tutorial at the request of a couple of Windows system admin friends of mine (at a company where I worked earlier), who were tasked with managing a few Unix boxes, without knowing Unix. They used the tutorial and later told me that it helped them to quickly start using vi to do their work on those boxes, including editing config files, simple shell scripts, etc. Edit: Since vi is mostly a subset of vim, the tutorial works for vim too.