"We've done a cool $50 million of R&D on the Apple Human Interface. We discovered, among other things, two pertinent facts: (1) Test subjects consistently report that keyboarding is faster than mousing. (2) The stopwatch consistently proves mousing is faster than keyboarding."

http://www.asktog.com/TOI/toi06KeyboardVMouse1.html

It's very easy on HN to find the pro-keyboard arguments. The pro-mouse argument is, more or less, that the context switch that really costs you time isn't the one involving the mouse, but the one involving remembering and/or finding the keyboard shortcut or function key.

Vim and Emacs style movement commands are faster than the mouse in certain contexts, but I'm dubious that's universally true. "I want to jump to line 123" is easy, but what about "I want to move the cursor to the open brace character right there"? No matter how much of a seasoned pro you may be, you're going to have to think for a moment about how to do to that: "let me count the '{' characters between the current point and where I want it to be. Three, so '3/{<cr>'." The mouse may make you move your hand, but it doesn't make you have to stop and count.

(It's also worth remembering that while mouse selection may not be as rich as "select within brackets" type commands, nearly all editors do have basic semantic mouse selection: double-click and drag to select by word, triple-click and drag to select by line. This can be a lot faster than you might think.)

The $50 million (in 1989) research figure sounds impressive, but they don't say how much of that was keyboard-vs-mouse research and the answer is quite likely "very little".

It seems that, like most UX research, they were testing how well novices manage rather than how well people do after weeks of experience (the latter is expensive to test!).

When you get to "It takes two seconds to decide upon which special-function key to press. Deciding among abstract symbols is a high-level cognitive function." it's clear that what they were looking at is a very very long way from how a typical Vim or Emacs user works.

I think the article _is_ interesting as evidence for the proposition "it's possible for people to believe that they're quicker with the keyboard when they're not". But it's nowhere near enough evidence to get as far as "we can dismiss people who believe they're quicker with the keyboard as mistaken".

You could certainly reproduce those results - if the only program you test them with is MS Wordpad. If you're doin surveys involving editors that have a thought-through keyboard interface and with people who are actually trained in it, the result would never even be in the same ballpark. What we're looking for is the skill ceiling, not the skill floor.

Here is what's annoying: having to frequently move back and forth between the keyboard and mouse. Having to glance down to find the mouse to do one thing and then back to keyboard starts to break one's train of thought.

Do people still consider the results of this study valid? A mouse in 1989 was nothing like a mouse now.

But vim doesn't make you count either... press "/{" and then repeat "n" until you land on the correct character. Also for selecting lines shift+V and jk{} etc will get me there with no counting. I've used vim for years and I never count I just use visual mode.

Touchpads make it super easy to deal with acceleration better I found.

However, with regards to your example, things like easy motion/avy solve this exact problem, I think no slower than a mouse. You basically punch in one, two, or more characters at the place you want to jump (depending which package/command you call), and then every match on the screen is highlighted and replaced with a different letter. Then you press that letter and jump there.

Not arguing that's it's much better, just that's approximately the same. Check it out: https://github.com/abo-abo/avy.

Check out avy-goto-char! In my setup, `<SPC> j j {` and then one or two homerow keys would move the cursor there. And the rest of the avy functions are useful as well: https://github.com/abo-abo/avy/blob/master/README.md

There are other options too that can be situationally more efficient, but avy-goto-char is faster than reaching for your mouse (at least anecdotally) and you don't have to think about.

I think that you have not learned to move around efficiently in vim. I would never enter that curly-brace command. I think most of my moving is with w, which jumps one word at a time. I also use / to search and page up and down. It sounds like you may be using harder commands than I do.

Becoming efficient with vim takes a little effort and practice, and you seem to have not committed to one single editor. You can't expect to be very good at every editor at the same time.

I suppose I'm not a Vim superstar, but I've been using it since before the 6.0 release, and still use it today. You're right that it's not the only editor that I use, but it turns out that even if you can't be very good at every editor, when you've been using computers for nearly four decades you can be reasonably good at two or three.

This plugin solves the curly brace issue. I find if there is something you find repeatedly annoying, there is probably a plugin to solve it. That or you suddenly have an interesting side project!

For example, I can very quickly run a "full build" by pressing Shift+F6 and simultaneously turn my attention to the build output. Doing the same with the mouse, I would need to move the mouse pointer to the "Build" menu, after possibly spending a few seconds awkwardly looking for the pointer across multiple screens which vary in resolution/scale, click, move again down to the "Rebuild Solution" and click. Then at some later point in time, possibly have to reach out and move the mouse for the sole reason of getting the pointer out of the way of my field of view.

True anecdote: more than once, doing the operation the "GUI" way in the past, while trying to find the right windows, has truly derailed my train of thought as to what my next operation was to be.

Also, I may just be an old-schooler as well, cutting my teeth on command line OSes and network environments (Netware v3.11 anyone?)

That said (subjectivity ahead), the mouse becomes annoying only when I'm done thinking, and it's time for doing. Imagine you've got your window manager set up just so, terminal multiplexer sessions all pointed in the right places; and finally, a problem -- and clear solution -- in mind. All that's left is implementation.

You start typing your solution, switching windows to compile or refresh a webpage every now and then. Things are coming together. As you proceed this way, a stroke of brilliance hits you, and you add an extra flourish that resolves an entire class of problems. Welcome to the "Flow State."

Finally, you realize you'll be needing a file from your Teamviewer session with another computer. You foreground that process, and navigate to the remote computer's file manager. So far, you haven't even had to traverse farther than three keys from the homerow.

Unfortunately, to transfer a file over Teamviewer, you'll need to use the mouse. You'll have to click three times to get to the file sharing widget, and use the mouse even more to get your remote/local directories lined up, another click elsewhere to initiate the transfer... close the little confirmation popup that's now obscuring your screen. It's not the end of the world, of course, but your dance has been interrupted.

I'm not sure you'll relate to anything I've stated above, and I'm by no means advocating "going mouseless" as objectively superior to your own preferred flow. Whatever works for you, works for you. I am hoping that my reply might help you get in the head of a keyboard jockey.

By the way, this reply was written with a rather fluffy cat sitting on my mousepad. So I'm not the only one to be inconvenienced when I have to switch to a mouse. Needless to say, George is a huge fan of vim. :)

I might be a professional when I'm in the zone at the office, but will become a regular user browsing out of curiosity at night.

tldr: the efficiency of the keyboard is contextual.

Als, if you do other actions than "goto definition", you'll also lose that speed very fast. In VS, "find occurrences" is burried somewhere in a rather convoluted context menu, while I can perform the according hotkey (C-k C-r) in a split second.

In eclipse you right click the function and the "show callers" is right there. Along with keyboard shortcut so I have the chance to learn it. Along with all other options so I see them and can learn them too.

It is not as if keyboard shortcuts were mutually exclusive with using mouse - unless someone decided that one of these devices is below him. Majority of people uses both and switch between them fat.

Of course, nobody said that. The mouse is one of the best user interface devices that has been designed for computing. Just not for working with text.

Now nobody condemns you if you like to use the mouse for browsing your code. However, if I'm right in reading your comment as rather snippy (hard to tell on the internet ;-) ), you seem to be very ready to do that to everyone seeing the merit in getting more proficient with their keyboard...

But I've got a mouse too. I use it all the time. It breaks up the repetitive in RSI. I think this is a good thing. We're not all trying to break the record in Mavis Beacon anymore. Most developers agree productivity is not measured in lines of code and yet some seem to still insist that a few seconds at most to move their hands and use the mouse is hurting them somehow.

Imagine yourself working as a photographer using non-digital cameras. While you know exactly what you want a picture to look like, you can't tell how it actually looks without some major work (i.e. process your film). So, you have to a) take many pictures of the same motive and b) try again later if you're not statisfied.

Of course, you can get very proficent using analog cameras (a trained eye could e.g. certainly tell the proper aperture adjustments for a scene), but you'll have to train that rather inefficently, too. And sure, digital cameras have their drawbacks, but they have a very net positive effect on most photographer's work, that's why you almost find no one using the old methods anymore.

Now, you - as the "analogist" don't recognize all the factors that slow you down in your work. It has been that way for decades, right? It must be the proper way to do things. Now imagine I'm coming along, being used to use digital cameras and forced to use analog ones in your working environment. Can you imagine the frustration I'm going through?

I just want to make a picture of what I need and tell if it worked, if my last two seconds of activity will do. But the old thing has no screen I can use to see if the picture was to bright, to dark or even blurred. That's what the mouse-based workflow feels like after a while: It's unnecessairily slowing you down, constantly standing in your way. No matter if it's not the activity you spend most of your time with - it prevents you from going back to your real work as soon as possible. And if you're used to do the same things without it, you'll very likely get frustrated some time.

Edit: I just realized another good metaphor would be to compare old FORTRAN punch cards (punching them out, giving them to an operator and waiting until the next day for the results) vs. debugging a modern C# application. That'sessentially what you're doing with proper hotkeys: Tightening your feedback loop.

I use Vim-bindings pretty much anywhere privately (to the point of using qutebrowser and an awesomerc file that allows me to switch workspaces using hjkl), but am forced to use VisualStudio at work.

VsVim makes VS barely usable for me, but it still has so many usecases that are mouse-mandatory that I'm constantly cringing. When programming is mostly thinking, I want to spend my time doing that and not slowly pushing a pointer along on the screen. The whole dialog-based systems basically constantly interrupt my thinking flow, and context switches aren't free :-)

Programming can seem like a slow process because the bulk of the process happens in our minds. Keeping our focus on our precious mental models makes us more productive.

Keyboard shortcuts become mechanical. When we're in the middle of editing code, whether we type "F8" "C-c C-l" or ":make", we can keep your focus where it belongs. But if we use a mouse to click on the "Build" button instead, we lose part of our focus looking for and aiming at the button. Menus and file explorers are especially bad at this: when opening a menu item or looking for a nested file, every single subfolder or submenu steals more of our focus away.

I know a few programmers who never use auto-completion for file names or methods. It surprised me and frustrated me a lot at first. Typing long file names without tab completion can be so. much. slower. But then I realised we can be much more efficient that way! Auto-completion interrupts our focus. We need to take in new information and make decisions. It's all about eliminating the step where we ask ourself "Why did I open this file?" or "What goes next?". It is easier to think about what arguments we want to pass to a method when we're not focused on selecting that method from a drop-down list. That is also why precise touch-typing is so important. We don't want to focus on either the pointer or the keyboard, we want to focus on our code.

The mouse itself isn't the problem, in fact some editors such as ACME or Blender make very good use of the mouse. The problem is inefficient UI design that interrupts our concentration.

Maybe that's just because I haven't gone through the learning curve, but I suspect the difference would be negligible.

[Edit] That's only for keybindings that force me to input string though, I vigorously use keybindings.

Unless it's part of your "inner loop" of productivity; investing there yields high yields in terms of translating thoughts to actions.

Simply lower your mouse sensitivity. Now you use your mouse by moving your entire arm instead of your wrist.

Watch how this guy uses his mouse: https://www.youtube.com/watch?v=X89152oocsA

Of course they do it to aim better, but it also puts less strain on your wrist and hand

I can hunt and peck and still be relatively efficient at editing. So I can move my hands from the keyboard.

Besides, even if I'm thinking more than I'm coding that doesn't mean I'm okay with the coding part being slow.

Combine that and modifier keys, and it's completely possible to have the mouse involved in intelligent actions, just not nearly as widely implemented as one might hope.

There's a balance there and it goes beyond even the task you're engaged in. I often find myself annoyed at the very same piece of software for providing too few keyboard shortcuts, or providing too few mouse interactions, depending on whether i'm working on something to the side, have one of my hands occupied, or just plain are having pain in one of my joints on that day.

People who proclaim one or the other as the alpha and omega seem to me stuck in a mindset that's strictly binary and refuses to see shades. (Granted, i am speaking with decades of entrainment. I can absolutely see how for a sysadmin in their 40s there may be little sense in trying to get comfortable with a mouse.)

My keystrokes are used on a bunch of custom shortcuts that I use to quickly navigate and read code.

It becomes a lot more debatable when you're modifying existing code (rather than writing new code).

There are actually lots of cases when the thinking takes a small fraction of the typing, e.g "this block should be extracted as a separate method", "this class needs to be renamed", "this interface should be split" ... or, even more obvious "this file needs to be properly indented".

We have automatic tools for some of these operations, precisely because doing them manually might spend a ridiculous amount of programming time.

I jest, mostly ;)

Personally, I need the slight downtime of using a mouse when compiling a program, a short moment to pause and clear my head. Without a mouse I'd probably be less productive.

Is it a big deal? I suppose it depends on how much you think in terms of whole sequences of commands.

The faster you finish the mechanical process of typing code, the faster you can get back to deliberation.

The responses to your query make me think keyboard-only is rice.

Anyway, it sounds like you're asking, "Why are keyboard shortcuts faster than moving a mouse to a location and then clicking [and potentially having to move to another location, such as the menu that just dropped down, and clicking again]?"

Does this really need an answer?

- Page up/down (and especially with home row shortcuts like in Emacs and Vi)

- Brace match jumps

- n line jumps up or down in Vim

- top/mid/bottom of view jumps

- page shifts up and down without moving the cursor

- top/bottom of file jumps

- jump directly to a line in a file

... and more

Seriously, put an Emacs or Vi power user next to a guy with an IDE and a mouse, and it's no contest.

1) I'm reading through code, and scrolling one line at a time with j/k is fast enough.

2) I'm looking for a specific point in the code, in which case I use search to get to it.

3) I want to go to the bottom or the top of the file, in which case G/gg are much faster than scrolling.

Sometimes I might use Page up/page down to skim a file, but that's relatively rare.

It's only ever one to two keystrokes away. You press '/', enter your phrase, and press ENTER. Stepping is done with 'n' and 'N'. There really are no convoluted hotkeys for this - which means that you do it much more liberally once you're accustomed to it.

Also there's '*' and '#' to quickly find the next/previous positions of the word your cursor is currentl located on. The same thing applies there.

Just scrolled down 80 lines