Deciding to use an editor is not an event but a process. Its making gradual investments over time, those investments make you productive.

If you are a manager, its worth your time to study tools that help you manage things better. If the best managers in the trade say a particular tool 'x' helps them be productive, then its worth your time to learn that tool. Can you justify minor leaks in productivity while you are learning it day to day. May be no on the shorter run, but the productivity gains over time are going to be so drastically huge its going to be totally worth your time.

If this manager goes to his senior manager and explains all this, I believe the senior manager would understand this. Else these so-called managers are not managers. But glorified desk-supervisors, whose only job is pushing buttons on the blackberry.

Managers like you are the reason why I quit my day job and started a thing on my own. Best decision I ever made.

And yet, the only thing you know about me is that I am not willing to grind my team of over ten programmers to a halt just to have them learn a tool (any tool, not just vi) that offers no quantifiable code quality or project-level productivity enhancements at all. By some accounts on other threads, mastering vim isn't a one-week stint, it could take weeks.

If you are saying that, in your own business you make decisions that would bring your entire team to almost an absolute without solid business or product quality justification. Well, more power to you. Live long and prosper.

This is hopeless. You clearly have no interest in understanding what others are trying to sayto you. You came here to flame and it seems that is all you wish to do.

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:

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

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.

Thanks.