That is simply not true. Not one person has offered any data to support the assertions on vi efficiency. Not one. All I have gotten are the equivalent of "because we say so". I am not flaming, I am not caving-in to the bullying, which is a different matter entirely.
In the interest of being constructive I decided to clear the bad blood and start another thread that is designed to educate us who might not understand why some are so passionate about vi. Here it is:
If those who post to this new thread stay within the proposed framework what will come out of it is a set of recipes that show (and support) the claims about vi efficiency. I hope you will be one of the first to join that thread and offer a few examples. There are many who know absolutely nothing about vi. Some have avoided it like the plague. And then, those like me, who only use it when absolutely forced to. This is an opportunity to educate all of us. Thanks in advance. I think it is safe to say that this thread is over (save those who want to talk about the foot-pedal).
I suspect there never will be data, because there's too many variables (including developer skill levels), that measuring 'efficiency' of an editor is a pointless exercise.
I use vim sometimes locally, but almost exclusively remotely, because the context I'm in at the time precludes using 'real text editors' - GUI apps that get installed and have menus and such. If I have to deal with files on a remote box (example: to edit config files), pulling them down to edit in notepad is highly inefficient. Vim is far more efficient - my own data over the last 15 years proves that to me, and generally to other people who watch me, and I say that as someone who really disliked ssh/vim processes - I preferred to pull down files via FTP, edit, save, then FTP up. But efficiency won over after experimentation.
But that's just one context. I use intellij, phpstorm, zend studio and visual studio for different types of editing, and those editors provide a wealth of other tools that make my editing far more efficient in those contexts (development, debugging, creation, testing, etc).
So "vim efficiency data"... likely never to happen, but "eclipse efficiency data" or "emacs efficiency data" won't happen either.
I am in complete agreement with everything you said.
I too have had to administer and support remote systems where vi was the only viable way to edit config files and the like. And, much like you, if I could, I would go for bringing the files into my local system for editing with a non-vi editor (a secondary reason being that if I screwed something up by accident I wouldn't take down a system).
In over twenty years of programming my intersection with being forced to use vi was never frequent enough to warrant spending the time to get good at it. None of my work suffered for it, of course. In my current business nobody uses vi and we get quality work out the door like anyone else. And, I should say, without the need for foot-switches :) --had to throw that in for a little dose of levity.
In the interest of being constructive I decided to clear the bad blood and start another thread that is designed to educate us who might not understand why some are so passionate about vi. Here it is:
http://news.ycombinator.com/item?id=4145060
If those who post to this new thread stay within the proposed framework what will come out of it is a set of recipes that show (and support) the claims about vi efficiency. I hope you will be one of the first to join that thread and offer a few examples. There are many who know absolutely nothing about vi. Some have avoided it like the plague. And then, those like me, who only use it when absolutely forced to. This is an opportunity to educate all of us. Thanks in advance. I think it is safe to say that this thread is over (save those who want to talk about the foot-pedal).