[chipotle_coyote]

I suspect a lot more of it is perception than people imagine: keeping your hands on the keyboard all the time seems like it intuitively must be faster. Early research in human-computer interfaces suggests that this isn't actually the case, though. From 1989:

"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.)

[mjw1007]

I wish people would stop citing that old AskTOG article.

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".

[btschaegg]

This this this. Citing articles like this and completely ignoring the setup of the experiments is one of the major pet peves I have with discussions like this one.

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.

[mtdewcmu]

I don't understand what task the users were doing when the mouse was discovered to be faster. The keyboard and mouse are not generally interchangeable; the task will generally favor one or the other. I'm assuming that the users were doing something like manipulating a GUI that favored the mouse and was awkward with the keyboard. The purpose of the study was probably to convince people to buy Apple's new mouse-centric computers.

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.

[mjw1007]

As far as I remember, in the one study that got reported users were asked to select a number of words scattered through a document and make them bold.

[mtdewcmu]

Oh, I get it. There was probably no efficient way to move the cursor around with the keyboard. That might explain why users said the keyboard was faster. It was faster for them to push the right buttons. They might have found the mouse cumbersome. They probably thought of the mouse wasting their time.

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

[to3m]

This is the sort of thing the mouse is actually rather good for. Though you're probably better using Ctrl+B to embolden than you are the toolbar or menu.

[mtdewcmu]

It sounds like roughly the best case for the mouse and roughly the worst case for the keyboard.

[JupiterMoon]

> 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.

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.

[chipotle_coyote]

I'm not positive that's going to be faster in every than using the mouse, though, still. And selecting lines with a mouse is, in most editors, triple-click and drag. I'm not saying that's necessarily faster than using visual mode--just that, again, it's not necessarily slower. It seems to me that cognitively they're fairly similar, and it doesn't feel to me like using the keyboard is conclusively faster in this circumstance.

[JupiterMoon]

It comes down to personal preference and makes only minuscule differences in the grand scheme of a job that is mainly thinking not typing.

[lathiat]

The MacBook Pro setup is faster again because I can use the mouse with my thumb without getting off the keyboard (and the trackpad works very well). Even with the trackpad I use on my desktop I have to move my hands backs and forward.

[microcolonel]

Have you ever tried a trackpoint? It seems like it'd be right up your alley.

[lathiat]

Yeah I find it very hard to be precise with the trackpoint, it's probably possible but most of the time generally seemed to move too slow and then hard to zero in on the target.

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

[chipotle_coyote]

While I'm not the person you're replying to, I always felt like I should have liked the trackpoint more than I did. I could never manage very precise movements with it -- and I learned that if you flail around with a pointing device, it's definitely slower than a keyboard, even if it's built into the keyboard. :)

[quicknir]

I use vim style bindings but agree that vimmers tend to exaggerate about the benefits. I think it works fine and so does a mouse and it's a small impact in the grand scheme.

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.

[chipotle_coyote]

I'd forgotten about easymotion -- I remember installing it years ago and taking it back out because it seemed so alien, but it's very clever, and I definitely believe that in practice it'd be fast, too.

[molloy]

> but what about "I want to move the cursor to the open brace character right there"?

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.

[chipotle_coyote]

Someone else mentioned avy above, too. I should definitely give it a look.

[mtdewcmu]

I think I avoid using the mouse with vim. It's not about the mouse per se, it's about having to frequently switch back and forth that becomes frustrating.

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.

[chipotle_coyote]

I appreciate the lesson, but that wasn't a curly brace command. What I said was typing "3/{", which seems like it's what you're suggesting: "/" to search for the "{" brace, but prefixed with "3" to jump to the third brace, which matches my example. You could do that with "/{" and two "n" keystrokes, but hey, that's one more keystroke.

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.

[mtdewcmu]

My mistake. I would search for the brace and then press n twice.

[sdflkd]

https://github.com/easymotion/vim-easymotion

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!