Maybe not. Efficiency is a measure of the time it takes accomplish something. 'Puzzling out how' can sometimes be a more relevant bottleneck than 'number of keystrokes.'
However, if, with a minute of thinking through the correct incantation, you can turn that into 10 keystrokes and no mouse movement, next time it will probably only take you 40 seconds to remember how to do it. Then, 30 seconds. Then, 20 second. Then, 10 seconds. Soon enough, if you do it often, it'll become automatic. And then you'll have locked in a more than 10x gain in productivity which would have been impossible the dumb way.
This is also the reason we spend years learning how to program instead of just copying and modifying bits by hand, by the way.
Within those full programs, there are many times when we continue to have a choice between doing it the quick but dumb way, or taking a little more time and doing it the clever and reusable way.
Of course, sometimes this can be taken too far - see yak shaving - but there are many points, while learning to program and while programming, where we face the choice between "do it manually in half an hour" and "take two hours to program something that will do it in 3 seconds". The difference between a programmer and a non-programmer is, largely, that given this type of choice, the programmer will tend to pick the latter option.
Your point is indisputable. Fortunately, it's not inconsistent with my own:
>> [Optimization is sometimes harmful.]
Optimization pays the greatest dividends to tasks which:
(1) could be brief,
(2) but are quite long and
(3) frequently necessary.
As to vim: On (1), brevity, Vim is powerfully so.
On (2), length, I don't recall any of my meta editing tasks involving "100 keystrokes and a mouse movement." Customizable shortcuts can trim down the outliers.
On (3), frequency, this surely depends on the person and task. I rarely delete every third occurrence of x between the seventh and ninth y... but if I used vim, I would make a point to.
So, I would turn to vim if there were several meta-editing tasks I routinely performed, each requiring a large number of keystrokes, each of which vim could reduce.
And hey, maybe this is the case. I'd love to see a plugin that analyzed my editing style and made suggestions to make me more efficient.
But originally I was just noting that efficiency and optimization are messy.
As a simple example of that, using a dumb text editor like notepad as the baseline, changing the same 10 characters on 10 consecutive lines will take at least 200 keystrokes (100 DELs, 100 times typing the same characters back in, plus the movement keys - about 9 to move down to the next row.
With a bit of thought, in notepad, you can reduce this a bit. use Ctrl-C and Ctrl-V to reduce the amount of typing - but you'll still need to either DEL or select the words to replace, in the same location on each line.
With a more modern text editor, you can select a rectangular area and replace the text within it. In vi, replacing those 10 strings on 10 consecutive lines will take (starting at the first character to replace, like Notepad, and assuming it's a single word inside separators):
Ctrl-V e 1 0 j c A_NEW_WORD
That's 16 keystroke instead of over 200, with no mouse movements.
This is something I do frequently enough that I didn't need to even think for a millisecond to bring to mind the keystrokes needed to do it.
Now, I'm not arguing your editing style isn't different - maybe you've never needed to do this - but I would argue that this is a fairly common programming text editing task.
1. Ctrl-shift-Right to select (1 or 3)
2. Ctrl-C copy (1 or 2)
3. Ctrl-H Open replace dialog box (1 or 2)
4. Ctrl-V Paste the old (1 or 2)
5. Tab (1)
6. A_NEW_WORD (10)
7. Enter (1)
8. Replace (1) x10 (or Tab + replaceAll == 2)
9. Escape (1)
-------------
Total 27 or 32
That >80% Better.
1. Right Click Key (1)
2. R - to choose refactor (1)
3. R - Rename (1)
4. A_NEW_WORD (10)
5. Enter (1)
----------------
Total: 14
c = (k.d.t.r) / 13333337
Where:
c = click
k = keystroke
d = distance in centimeters between the "J" key and mouse
t = area to be clicked in pixels²
r = screen resolution in pixels²Here's an example, I want to change the name of my MyClass.Execute() method to something more descriptive. In an IDE, I right click and rename and I'm done.
In vim or other plaintext editors this is practically impossible without manually inspecting each call-site. Is "foo.Execute()" a reference to MyClass.Execute() or YourOtherClass.Execute()? Without actually parsing the program it's tough to know.
I love using vim, and I'm getting better at it the more I use it, but this is one of the major productivity drains I encounter that an IDE does way better.
- braindead configuaration files. - data files that need some massaging - commenting out code blocks in languages which need a prefix comment delimiter on each line (e.g. python's # or haskell's --) - any time you are doing a series of operations calling functions in a module or from a single class/object and the name changes (e.g. foo.x();, foo.y(); foo.z(); and so on);
We changed the data format being sent over JSON now I needed to:
1) make a bunch of int declarations into float declarations, fortunately those tend to bunch up.
2) Change a bunch of getInt calls to getFloat calls, but those are also bunched up together.
Another approach is something like:
*:.,+9s/<ctrl-r>//A_NEW_WORD
(I post this now because it was closer to my first thought on how to approach the problem, and wanted to write it out to see if it was shorter. It wasn't, but maybe it'll be useful to someone. I learned about <ctrl-r>/ (fills in a search and replace with the previously searched expression), while writing it.
It's not about the most efficient command sequence at every moment in time, rather it's about building up the mastery that allows your natural instincts to subconsciously pick more efficient paths.