I am going to ignore the first part of your comment because, well, I asked that this thread not go that way. The problem with the other thread is that claims were made about vi efficiency and not one bit of data of any kind was provided to support these claims. Nobody learns this way. This thread is already very different as many have provided very interesting comments with valuable insight, including yourself.

I understand flow very well of course. I can't say that I've ever used an editor that prevented me to enter that state. I a not countering your statement, just providing my own experience.

Aside from programming I play the piano and classical guitar. When I play music I am in flow. That didn't happen until I had reasonable command of the instruments. With vi (or any other tool) the same is required. I wonder how much time it would take to go from vi neophyte to playing it like a piano? That initial phase is painful if you have to get work done.

I also understand the value of playing a good instrument and using good tools. And, while this value may not provide any hard quantifiable benefits to the project timeline it does provide benefits for the practitioner. The project might still be six months late, but there will be more daily enjoyment, if you will, for the practitioner to remain on focus. That could have value. Whether or not there is a difference between someone who has never touched vi and a vi expert remains to be determined. The vast majority of programmers don't use vi.

After reading your post and others on this thread my immediate reaction is that vi advocates might want to consider not characterizing vi as "more efficient" but rather highlight what it might do for a programmer. I can't come up with the words right now, but "more efficient", in my book, calls for having quantifiable data at the project level (not the file level).

We all know that saving a few keystrokes here and there isn't going to bring a project to conclusion any sooner. We had a project where we spent six months tracking down a bug that was due to a rounding error someone made in a calculation of lookup-table data used in a polyphase FIR filter module. It was one of those things that was right in front of you but nobody could see it. The project was late by an additional six months (it was already late) because of that bug. That's the kind of thing I think about when I say that saving a few keystrokes on the editor doesn't matter in the context of a project.

I'll read the article you pointed out and see what else I can learn.

Thanks for your input and valuable insight.