Apple discovered fairly early on that while using a keyboard shortcut seems faster, using the mouse is almost always quicker, even for very advanced users. The illusion stems from how we perceive time when performing the different tasks - we remember time spent searching for the correct target to click, but we forget time spent remembering the right incantation.
This paradox is one of the big reasons why I don't use Vi or EMACS - I think that the productivity gains are nowhere near as great as users make out, but the sense of mastery over such arcane tools is inherently satisfying to the kind of person that spends a lot of time in a text editor.
That's certainly interesting research, but it's far from conclusive. There are all manner of variables such as the accuracy of the mouse actions required, the number of keystrokes required, the familiarity of the user with the commands, and even the quality of the mouse.
The tests that Apple conducted were based on simple tasks available on the Macintosh computers of the time. However, text editing is a complex task with a lot of room for optimization. There is no doubt that more keypresses can be achieved per second than mouse actions, and that if asked to repetitively perform a task that could be accomplished by means of 10 vim key strokes or some combination of 5 text selections and menu choices, the max speed of the vim'er would top out higher than the mouser.
However true it is that the keyboarder forgets the time spent recalling arcane commands, it's also true that experienced vim'ers can issues multiple commands per second, some of which will do things that would not reasonably contained in a convenient location in a menu and/or icon-based interface. The powerful grammar and compositional nature of vi commands alluded to in this article, combined with the patterns that emerge in working with specific programming languages lead to opportunities to develop extremely efficient editing skills that blow a mouse-based workflow out of the water. It's not just my own experience, it's watching other people do things in vi or emacs that I guarantee are impossible with a mouse.
You may well be right that the improved productivity of vi/emacs is exaggerated by its practitioners, but I don't think there's really a case to be made that advanced keyboard editing is a waste of time.
Another thing that comes to mind is that using current devices (such as two 22" displays, i.e., a much higher resolution like 3360x1050), the time to do anything meaningful with a pointing-device increases, too. I, for instance, switched to a big trackball device because all this mouse lifting and re-centering became annoying.
As for the simple tasks: Something like Emacs macros enable effective processing of raw text input data--something that would take a lot longer if it had to be done manually, if possible at all.
After reading that long ago, I timed myself doing keyword searches on a webpage using both cntrl-f and accessing search from the menu. cntrl-f was significantly faster.
I agree that this is true in some cases but I can give you a counter example that really showed me how convenient vim is: ciw. 'ciw' erases the word under the cursor and allows you to retype it. This process is very, very slow using the mouse: even if double or triple click tends to correctly highlight the word you want to replace, positioning your mouse there is pretty slow.
Let's say I need to change a word. With Gedit, I double-click the word and retype it the right way. With Vim, I press j until I'm on the line where the word is, then I press w until I'm at the beginning of the word, then I press cw to change the word, retype it the right way, and press escape to go back to command mode.
Triple-clicking in Gedit highlights a line. Triple-clicking and dragging highlights a contiguous group of lines. In Vim, I'd need to move to the line I want to begin my selection on ([number]G or jjj), then press V, then press jjj until everything is selected. And I don't have to deal with the fact that the default way of deleting things overwrites the default clipboard either.
I do use Vim when I need to process lines in a text document (with macros), when I'm editing files on a server, or when I'm writing a git commit message. I suppose I could use Vim in much the same way as Gedit through its mouse capability, but I dislike the lack of interface between my system clipboard and Vim's, and the fact that when I paste code in to a Vim document, the indentation gets all screwed up.
"With Vim, I press j until I'm on the line where the word is, then I press w until I'm at the beginning of the word, then I press cw to change the word, retype it the right way, and press escape to go back to command mode."
OK, this is something Vim people need to work on. Using j/k to move more than one or two lines is the wrong way to do things.
I know, I know, we extoll the virtues of hjkl constantly, but really they're barely more effective than the arrow keys.
There are better ways to move around in Vim, such as [f]orward, '[t]il and searching. In your case (changing word XYZ to something else) I would search for the word with /XY… and press return to get there, then edit as you described.
"Triple-clicking in Gedit highlights a line. Triple-clicking and dragging highlights a contiguous group of lines. In Vim, I'd need to move to the line I want to begin my selection on ([number]G or jjj), then press V, then press jjj until everything is selected."
See my previous comment about movement. You'd move to the line you want by using a search (or '{', which moves to empty lines), start your selection with V, and move to the end with another search (or some kind of movement command that gets you where you want to go quickly).
We Vim users need to stop touting our Nethack-honed hjkl skills and start talking about Vim's better movement commands.
"And I don't have to deal with the fact that the default way of deleting things overwrites the default clipboard either."
Yeah, this is dumb. YankRing helps a lot by letting you 'Ctrl+P' to the right text, but I really think Vim should have a "clipboard register" that only gets overwritten when you mean it (and have other registers for the last yanked elements).
"when I paste code in to a Vim document, the indentation gets all screwed up."
If you're using a graphical Vim like gvim or MacVim this simply shouldn't happen. It's a bug and you could report it.
If you're using the command line Vim you might need to do a bit more work to launch Vim and tell it to talk to X. It's a few extra minutes up front, but such is the price of using a terminal-based editor in a graphical environment.
"There are better ways to move around in Vim, such as [f]orward, '[t]il and searching. In your case (changing word XYZ to something else) I would search for the word with /XY… and press return to get there, then edit as you described."
That is both slower and has the disadvantage that any intermediary occurrences of the word between my cursor and the one I want to edit will be accessed first.
"See my previous comment about movement. You'd move to the line you want by using a search (or '{', which moves to empty lines), start your selection with V, and move to the end with another search (or some kind of movement command that gets you where you want to go quickly)."
I invented the following task for myself: With the cursor on a blank line above 4 lines of text followed by a blank line, copy the 4 lines and paste them so that there is a buffer of 2 blank lines between the 4 lines of text and their duplicates. I did the task 4 times in both gedit and vim, restarting whenever I screwed up (which was quite often). Here are my results.
vim: 18.28s
gedit: 14.45s
I discarded an earlier task that I think Vim might have been doing better on because the task ended with the buffer back where it started, and I wasn't sure I was able to count accurately while performing the task. However, I had practiced with Vim on that task to the point where my movements were purely mechanical, and I was typing characters nearly as fast as I'm typing these words now.
It's probably a better idea to relax while doing these tasks instead of racing through them, as I'm generally relaxed when I code, but I still don't see much promise in Vim at this point.
As a side note, why is it that I'm the only one doing tests on myself? It's almost as though you guys don't actually want to know which editor is faster.
I tried your test, and was slightly faster at doing it vim than gedit (assuming my fingers were on the keyboard to begin with). How exactly did you do it in vim? I used the following:
y4j5jp -- yank down to 4 lines, move down to the blank line, paste after it.
I appreciate that there's an awful lot to learn before you can edit quickly in vim, and that the difference (if any) between that and gedit(or any other editor) may not be worth it.
I prefer vim for reasons other than speed, though -- the composable commands "feel" right to me, and the macro system makes short work of repetitive tasks. I'm essentially making lots of small programs to write the larger program for me.
I don't know about other vim-users, but I haven't run any tests because my primary motivation for using vim isn't speed (it's that vim connects with my brain and my motor activity -- it just feels "right" and I get a great flow).
set mouse=a and the behaviour is the same, tripple click hilights a line and you can drag your mouse around to highlight a contiguous group of lines.
regarding the system clipboard, yeah thats messy, but you can easily map a key to toggle the paste mode (set pastetoggle=<f11>) or get the content from the the clipboard via some keybinding (shift-F7) map <S-F7> :r!xclip -o<CR>
Reading your comment it is apparent you dont now "enough" vim. It has a long learning slope with many comfortable plateaus. You must be diciplined and interested in mastering your tools to push beyound these.
In my Vim vs Gedit test, I was doing tasks from the beginning of the Vim tutorial using the exact commands the tutorial told me to use.
It does seem possible to me that someone could become faster with Vim than a click-and-type editor, but I'd guess they'd never amortize the costs of their learning. (Of course, if you're already quite advanced then you've paid a good chunk of the cost and it may make sense to continue.)
The beginning of the tutorial doesn't necessarily have the most efficient way to accomplish a task. It just has the most basic way.
For example: move up 10 lines with 10k. Move up 2 paragraphs with 2{. Move up to "what" with ?what, and if it stops somewhere else first, just hit n. Find the first letter T in a line with fT, and hit ; if you stopped at another one first. Etc. You can't put everything at the beginning of the tutorial but having a lot of these tricks in your bag speeds you up quite a bit. Then you start combining these movements with commands, repeating these combinations with just a period, recording them in macros with a couple keystrokes, applying them to every selected line with :norm, etc. It's the combination of all these things that makes it go fast.
That said, if I've got a long distance to travel and there's no obvious movement command to get me there quickly, I'll still use the mouse occasionally. It does seem to break the flow though.
The biggest improvement vim has made to my productivity isn't just the raw speed of editing, it's the fun of editing with it. That keeps me a lot more focused when the work itself gets a little mundane.
To add to what Steve said, I would say: don't be afraid to use the mouse if you're in a graphical Vim. In MacVim, if I want to change a word, I'll double-click it, hit c and type whatever I want.
You might say, "But you had to hit 'c' instead of just typing!"
Maybe, but I could run any number of commands over that word instead of just changing it. Also, if I were in insert mode, double-clicking and typing would overwrite the word as if I were in a normal editor.
Generally, if you know where you're going its a lot faster to just start typing a search until you get to the word you want than to mess around with j and w (why incremental search isn't default eludes me). I won't claim that will always be faster than a mouse, but it should narrow the difference a lot.
I totally agree with you about the clipboard issues though.
No, you would type xxg, where xx is the line number, then move with w if the word was a short distance away, or use the mouse if it was somewhere like the middle of the line, then cw. This works out favorably even a Thinkpad where I don't need to take my hands away from the home row for, and it works better when working with very large screens.
Really what I'm wondering is whether the Vim way of doing things or the click-and-type way of doing things is faster. I don't see any really compelling advantages of Vim as a click-and-type editor. Gedit also has a plugin mechanism y'know.
