> Being more efficient at manipulating text means less energy spent, which makes for happier programmers. So the more efficient text-editing is preferred by som

> Being more efficient at manipulating text means less energy spent, which makes for happier programmers. So the more efficient text-editing is preferred by some, not because it leads to better software, but because it leads to better quality of life. And I stand by the statement that vi[m] is more efficient at manipulating text, while not disagreeing with you that it makes no difference at the project level. I can absolutely agree with you on that. Learning vi[m] in order to get to that level seems to be the hit lots of people are not willing to (or simply can't) take. In the context of a busy shop it makes almost no sense to bring productivity down to almost nothing while everyone has to slow down to learn a new tool (any tool, not just vi[m]). The only time one can justify this sort of thing is when there are real and measurable business or code quality benefits to the interruption. An example of that is sending everyone out to a one week course on a new technology. When they come back they absolutely rock. I've sent people out to take courses costing the company tens of thousands of dollars on more than one occasion. In every case it pays off within days. I can't say that about vi[m] yet. Not wanting to voice opinion from a context of ignorance I will spend time over the weekend to force myself to dive into vim and see what I can learn. Happy programmers, hell, happy people, are always more fun to work with and be around. If vi[m] can bring that to the table I have no problem promoting its learning and usage at our shop (when we can afford to take the initial productivity hit while everyone learns).