Show HN: Nomouse(github.com)
github.com
Show HN: Nomouse
https://github.com/brhs/nomouse
172 comments
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.)
"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.)
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".
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".
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.
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.
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.
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.
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.
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.
Do people still consider the results of this study valid? A mouse in 1989 was nothing like a mouse now.
> 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.
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.
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.
It comes down to personal preference and makes only minuscule differences in the grand scheme of a job that is mainly thinking not typing.
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.
Have you ever tried a trackpoint? It seems like it'd be right up your alley.
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.
Touchpads make it super easy to deal with acceleration better I found.
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. :)
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.
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.
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.
> 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.
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.
Someone else mentioned avy above, too. I should definitely give it a look.
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.
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 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.
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.
My mistake. I would search for the brace and then press n twice.
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!
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 me, the difference between keyboard shortcuts, and command line interface for that matter is that the same operation can be done semi-autonomously with the emphasis being on the variation (filename, path, flags, etc.) for the task at hand (no pun intended?). Performing the same operation with the mouse, there must be proper "setup" (get windows visible, or at least open to Alt/Cmd+Tab between them), and deliberate, visually tracked, hand/eye coordinated operations to perform the same operation.
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?)
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?)
I think I can speak from a position of genuine dislike of mouse usage. I enjoy it for certain things, like perusing the web, or clicking through tickets while sipping on a morning coffee. The mouse is a great invention, and I would never want to get rid of it completely.
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. :)
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. :)
Not just you, keeping yourself in the flow is why many professionals prefer the keyboard to mouse. Note the word 'professionals', in contrast to a regular computer user browsing Facebook whose curiosity makes him want to easily click on anything that comes to the sight.
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.
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.
Navigating code with mouse is much faster then with keyboard only. Things like ctrl+click to see function definition or mouse over to see function documention, variable value or its type. Double click the name before I press shout cut for rename and so on and so forth.
Perhaps, if the only thing you're doing is actual navigation. As soon as you want to also edit said code, you loose said benefit since you're constantly switching between mouse and keyboard.
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.
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.
I either edit or navigate and switch between the two rarely enough. Obviously I don't type with keyboard.
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.
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.
> It is not as if keyboard shortcuts were mutually exclusive with using mouse
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...
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...
I'm of a similar opinion. I grew up watching my mother have surgery on both of her wrists for what used to be called carpal-tunnel syndrome and now is just called repetitive strain injury. I've spent probably triple the time by 38 years old that she had in front of a computer, full time developing software, on a standard, non ergo keyboard which is nearly the same (even has clicky button switches!) as the one from her era.
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.
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.
I don't think you can actually understand the issue if you haven't experienced it; that's just the way our brain works. I was extremely skeptical of Vim-bindings too, for example, and only learned them once I needed a powerful editor that compiles for ARM CPUs. While I don't use Vim anymore (mostly) I'd never want to go back in terms of the modal editing.
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.
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.
Funny thing, for me, this is exactly the reason why the mouse is annoying.
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 :-)
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 :-)
Using a mouse is distracting. It steals our focus away.
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.
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.
See, for me it's the complete opposite, typing words unrelated to the actual code makes me lose part of my focus, whereas navigating the mouse or a dropdown list isn't requiring me to "create" words or strings in my mind.
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.
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.
I agree to some point; I don't think keyboard shortcuts are worth learning.
Unless it's part of your "inner loop" of productivity; investing there yields high yields in terms of translating thoughts to actions.
Unless it's part of your "inner loop" of productivity; investing there yields high yields in terms of translating thoughts to actions.
Exactly. I used to be one of these hardcore guys typing fast and never taking my hands off the keyboard; then I got RSI and learned to appreciate value slow methodical approaches.
Interesting, I find I can type all day and not feel a thing in my wrists or hands, but just 15-30 minutes of continuous mouse usage, and I'm reaching for the pain medication. To me, staying able to use a computer without the mouse is about both speed and comfort.
This is a common problem in people who play computer games, especially those that are mouse heavy. The solution is pretty simple actually.
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
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
In other words, you got old and slow. Happens to us all :)
This is one of the reasons I started learning vim bindings.
I can hunt and peck and still be relatively efficient at editing. So I can move my hands from the keyboard.
I can hunt and peck and still be relatively efficient at editing. So I can move my hands from the keyboard.
It's not just that using the mouse is slow. The mouse is also dumb. By that I mean that you can't tell it to take intelligent actions like jump to/select/delete a particular semantic unit (e.g. a sentence). Using the keyboard allows for more intelligent actions and for composition of actions with (optionally) mnemonic keybindings. The mouse is far less precise and requires some UI for pretty much anything.
Besides, even if I'm thinking more than I'm coding that doesn't mean I'm okay with the coding part being slow.
Besides, even if I'm thinking more than I'm coding that doesn't mean I'm okay with the coding part being slow.
Just highlight the sentence really quickly. Do it enough and you get good at it. Just like with keyboard shortcuts.......
I forget which program it is, but I've seen at least one document editor where one click places the cursor where you clicked, a second selects the sentence it's within, and a third expands the selection to the whole paragraph.
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.
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.
How about firefox? I double click to select a word and triple click to select a paragraph.
Personally i see it mostly as self-validation. I'm in an odd position in that i learned computing with an Amiga, meaning a computer that has a mouse, but was also still unadvanced enough to require lots of keyboard interaction. Nowadays i find that which i use depends a lot on the current context. Exploring things and browsing documentation particularly is done almost entirely with mouse and mouse gestures. Editing text is very keyboard-centric and the mouse only gets to act occasionally.
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.)
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.)
[deleted]
I'm a keyboard-only developer with a very high key rate, but I don't write an above-average amount of code.
My keystrokes are used on a bunch of custom shortcuts that I use to quickly navigate and read code.
My keystrokes are used on a bunch of custom shortcuts that I use to quickly navigate and read code.
> I see blog posts all the time about how a programmer's job is more thinking than writing code and/or writing good programs is also about taking out just as much code as you put in.
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.
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.
The discipline of thinking before typing is one that requires experience.
I suspect that many young developers are stuck with not knowing what to type, and try to find solutions to their apparent lack of productivity (a guilt-free way of procrastinating).
I jest, mostly ;)
I jest, mostly ;)
I think it's one of these dogma that just get around by word-of-mouth.
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.
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.
Ergonomically, IMO, using a mouse or track pad is much worse than typing. That said, I am a very deliberate and methodical developer.
One important thing about keyboard is that it is a mostly uninterrupted buffered stream: with some notable exceptions, you can usually keep typing whether the previous command is done executing or not. You can type ahead several long running commands (in a shell, in an editor, for instance) and then let go.
Or, you can click, wait, click, wait, click and then finally switch to something else.
Is it a big deal? I suppose it depends on how much you think in terms of whole sequences of commands.
Is it a big deal? I suppose it depends on how much you think in terms of whole sequences of commands.
I don't understand this viewpoint.
The faster you finish the mechanical process of typing code, the faster you can get back to deliberation.
The faster you finish the mechanical process of typing code, the faster you can get back to deliberation.
To have some perspective from the other side, every time I try to use the keyboard I am immensely slowed because a large part of my brainpower goes towards remembering anti-intuitive keyboard commands. It reminds me of my short attempt to switch to a Dvorak keyboard layout.
The responses to your query make me think keyboard-only is rice.
The responses to your query make me think keyboard-only is rice.
I think the idea is that there are times when using the keyboard is faster than using the mouse, whether it's using a certain editor or knowing the program's keyboard shortcuts. There's also the time taken to switch between using the keyboard and the mouse. It's kind of a micro-optimization.
The mouse is good for browsing and uncommon actions through drop down menus. There are about 30-40 keybindings I use in emacs, which are the most primitive or the most frequented commands. The rest I find through the drop down menu.
There is no mouse in vim. You're a new-schooler.
An old-schooler would be the one asking, "why do I need a mouse?"
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?
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?
You forgot even more inefficiency: Lifting your hand off the keyboard and moving it to the mouse, [insert your above steps], then moving back to the home row.
No problem at all if you use a TrackPoint. I don't even have a mouse, I use the ThinkPad USB keyboard at work which includes a TrackPoint. I know some people dislike them with a passion, and they don't look fashionable, but I can't use a keyboard without one any more.
Is scrolling through source code really faster line by line?
There are so many keyboard options for moving through source which you don't have with a mouse...
- 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.
- 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.
As a vim user, I don't really find myself needing to scroll "fast" ever. Instead, there are three common cases:
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.
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.
Actually, this is also a point worth stressing for people without Vim-experience: Searching is a "first-class citizen" (as the FP-guys put it with functions).
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.
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.
That's what you do with a mouse though. With a keyboard, you can move by semantic units (like a paragraph or function), use fuzzy search to jump to a specific function, etc.
80j
Just scrolled down 80 lines
Just scrolled down 80 lines
I didn't forget. I just didn't feel like enumerating what I think are obvious and commonly accepted facts :).
It really comes down to thought->muscle memory of keyboard shortcuts, especially those which don't require moving hands away from the home keys, vs the activity of reaching over, taking the mouse, driving it to a certain location on the screen, and then clicking. It should be obvious which will be faster.
It really comes down to thought->muscle memory of keyboard shortcuts, especially those which don't require moving hands away from the home keys, vs the activity of reaching over, taking the mouse, driving it to a certain location on the screen, and then clicking. It should be obvious which will be faster.
[deleted]
If I could upvote this, I would.
Text-only browser (no Javascript) means I cannot upvote.
This might be an unpopular opinion, but it is one based in real experience: If you can ditch the mouse, then you can ditch the GUI.
I have not used a mouse on my personal computers in over 20 years.
This transition started as an experiment when I was sitting in an airport with a laptop back in the late 90's.
Remember those tiny joysticks implanted in the keyboards?
I decided to stop using them.
Then I started using PC's without using the mouse.
Then I stopped even connecting a mouse.
That eventually led to ditching the GUI and staying in VGA textmode.
Today the whole process is easy because we can own many inexpensive personal computers.
I keep at least one personal computer with a GUI but it is not directly connected to the internet and usually not even connected to the LAN.
When connected, its gateway is always a wired computer "I control" with no GUI, no touchscreen, no mouse, no trackpad driver, no wifi driver, no bluetooth driver, etc.
My non-GUI computers run from USB stick or SD card. Root filesytem embedded in kernel. Working filesystem (chroot) is RAM (tmpfs). No SSD or HDD required. No third party DNS required. IP forwarding is compiled into the kernel so I can turn it on or off should I wish to use as a gateway.
Text-only browser (no Javascript) means I cannot upvote.
This might be an unpopular opinion, but it is one based in real experience: If you can ditch the mouse, then you can ditch the GUI.
I have not used a mouse on my personal computers in over 20 years.
This transition started as an experiment when I was sitting in an airport with a laptop back in the late 90's.
Remember those tiny joysticks implanted in the keyboards?
I decided to stop using them.
Then I started using PC's without using the mouse.
Then I stopped even connecting a mouse.
That eventually led to ditching the GUI and staying in VGA textmode.
Today the whole process is easy because we can own many inexpensive personal computers.
I keep at least one personal computer with a GUI but it is not directly connected to the internet and usually not even connected to the LAN.
When connected, its gateway is always a wired computer "I control" with no GUI, no touchscreen, no mouse, no trackpad driver, no wifi driver, no bluetooth driver, etc.
My non-GUI computers run from USB stick or SD card. Root filesytem embedded in kernel. Working filesystem (chroot) is RAM (tmpfs). No SSD or HDD required. No third party DNS required. IP forwarding is compiled into the kernel so I can turn it on or off should I wish to use as a gateway.
You sound like you have a set-up that you've planned in support of a specific goal. What exactly is that goal? A lot of that sounds like it would make doing what I like doing on computers difficult.
[deleted]
If I could upvote this, I would. No Javascript means I cannot upvote.
? HN is oldfashioned enough that JS on vote buttons is progressive enhancement, not required.
? HN is oldfashioned enough that JS on vote buttons is progressive enhancement, not required.
It looks like the issue is the text-browser aspect, not the no-javascript aspect, there's no text displayed in the upvote anchor:
<a id='up_13847301' vote(event, this, "up")'
href='vote?id=13847301&how=up&auth=f483a3dbdbad30753751f31882cdbe1bf5cca2ce&goto=item%3Fid%3D13847301'>
<div class='votearrow' title='upvote'></div>
</a>I constructed a proper URL and submitted an upvote.
<a href="https://news.ycombinator.com/vote?id=13847301&how=up&auth=f4...
<a href="https://news.ycombinator.com/vote?id=13847301&how=up&auth=f4...
How long did that take you? For me it was about 0.2 seconds with touchpad technology.
I second the request for you goal or reasoning, not because I think you're wrong, but I'm genuinely interested. People might think RMS is crazy, but he seems to be always right in the end. You may be the RMS of mouse usage. :)
I applaud you, good sir. I've used Mac OS (classic) since a child, Windows since a teenager, and OS X sometimes at certain jobs. My most recent job rather forced me to use Linux... and now I find myself wishing for less and less GUI and more and more TUI.
Command lines really are far more intuitive to me than any GUI has been; my workflow in a software terminal is far more productive than any GUI application has ever allowed me to be.
Command lines really are far more intuitive to me than any GUI has been; my workflow in a software terminal is far more productive than any GUI application has ever allowed me to be.
> Remember those tiny joysticks implanted in the keyboards?
You mean this? https://xkcd.com/243/
You mean this? https://xkcd.com/243/
The Power Nipple!!!
After I discovered extensions/addons for vim-like control of browsers few years ago, I've completely changed how I browse the web. I rarely even use the mouse anymore. Only when I want to save an image or save a file (from a misconfigured server that doesn't auto-download) do I still use a mouse. For everything else, you simply don't need a mouse at all.
My favorites:
vimari - Safari port of vimium: https://guyht.github.io/vimari/
vimium for Chromium: https://chrome.google.com/webstore/detail/vimium/dbepggeogba...
VimFX for FF: https://addons.mozilla.org/en-US/firefox/addon/vimfx/
My favorites:
vimari - Safari port of vimium: https://guyht.github.io/vimari/
vimium for Chromium: https://chrome.google.com/webstore/detail/vimium/dbepggeogba...
VimFX for FF: https://addons.mozilla.org/en-US/firefox/addon/vimfx/
I've used the vimium for chrome, vimfx for firefox and they both have similar problems:
1) Impossible to navigate some sites 2) Slows down the browser to a crawl over time
Generally, not a usable long-term solution
1) Impossible to navigate some sites 2) Slows down the browser to a crawl over time
Generally, not a usable long-term solution
I use Vimperator, never noticed any slowdown effect. Why would that even happen?
It's true that some sites are harder to navigate, though.
It's true that some sites are harder to navigate, though.
Vimperator is the king among Vim-like keyboard shortcut enabler extensions in browsers, sadly it may not work in the future versions of Firefox because Firefox is transitioning from highly free but less safe/performing XUL based extensions to a safer but limited WebExtension model. It is very fast and smooth with lots of features.
RIP vimperator :(
I used vimperator and experienced crazy slowdown on Firefox in both OSX and Ubuntu. This happens after you browse for a while. Wasn't sure why initially. Things improved dramatically after reinstalling the addon. But I had to do it frequently so it wasn't worth it.
I think it's because things are saved in history for a long time or history chain of sites in a tab is very long.
Edit: Only extension that is vim-like that hasn't let me down is cvim for chromium/chrome.
I think it's because things are saved in history for a long time or history chain of sites in a tab is very long.
Edit: Only extension that is vim-like that hasn't let me down is cvim for chromium/chrome.
I'd heard about these before, but never tried them since I assumed there would be some case in which they didn't work, and it would be enough to be a deal-breaker.
But after reading this sub-thread, I decided to give it ago, and I've been absolutely blown away, such a pleasurable experience!
I've started using Feedbin for my RSS feeds lately, which makes great use of vim-bindings, and I've enjoyed using that site more than any other partly for that reason. Now I get that on every site - and as a bonus, adding an exception (so that I could continue using Feedbin's bindings) was easy.
The only thing that seems to be missing is a way to edit large text fields (like this one) in vim-mode. Though I understand there are separate plugins people swear by for that, so perhaps they work in conjunction, I'll have to explore that next.
But after reading this sub-thread, I decided to give it ago, and I've been absolutely blown away, such a pleasurable experience!
I've started using Feedbin for my RSS feeds lately, which makes great use of vim-bindings, and I've enjoyed using that site more than any other partly for that reason. Now I get that on every site - and as a bonus, adding an exception (so that I could continue using Feedbin's bindings) was easy.
The only thing that seems to be missing is a way to edit large text fields (like this one) in vim-mode. Though I understand there are separate plugins people swear by for that, so perhaps they work in conjunction, I'll have to explore that next.
I wish there was something like Vimium for Windows 10. I am trying to use hotkeys whenever I can, but some applications are expecting you to use mouse. In such situations I would give gold to be able to quickly select and click elements on screen by keyboard.
I'd love to use emacs key bindings to browse the web. Anyone have good suggestions?
If you use Firefox, try Firemacs [1]. I don't know if there's something similar for Chromium.
[1] https://addons.mozilla.org/en-us/firefox/addon/firemacs/
[1] https://addons.mozilla.org/en-us/firefox/addon/firemacs/
You might consider Conkeror. https://en.wikipedia.org/wiki/Conkeror
Do they help navigate the dev tools? The web pages I'm developing are all UU- and keyboard-friendly, which is great when I test them. But I'm having a hard time not reaching for the mouse because I need to use the devtools.
I use VimFX and Vimium daily. They're wonderful addons, and I browsing would be much more unpleasant without them.
I find this completely pointless. You wean yourself off the mouse when you have to use the keyboard for most of the work you do. Trying to trick yourself to do "the right thing" (if that's what this is about) is just silly.
I use the keyboard almost exclusively, and even had colleagues remark on it rather impressed about it I guess (I don't mind the hacker cred, let's be honest here). I never had to force myself, or try silly tricks to drop a habit. I just found myself in situations where either there was no mouse, or it was more convenient to use the keyboard.
First I was forced to use runlevel 3 only, for three months (gpu died and I didn't have any money). Then I had a long commute with only a wimpy netbook with Fedora ...14, I think? With Xmonad on it (because it's damn light). Then I had a job that was done best over a network with powershell and windows remote. Then I had to do a lot of text processing and it was best done using Vim [1]. Then I spent a year on Z/Os where you can use a mouse but the point-and-shoot fields are much more convenient most of the time (except for copy/pasting, strangely). Then I noticed the Windows' 10 tiling desktop manager and there was much rejoicement (it's gotta be a deliberate Xmonad ripoff!). And now of course Windows has a bash shell so there's never any reason to leave the command line. Yay!
On the other hand, it's true that prolongued mouse use hurts my wrist and I am a bit worried that I might get RSI in the long run, so I'm conciously keeping my keyboard habbit fed. I guess what I'm saying is that the main thing you need is a good reason to drop the mouse, rather than a silly carrot-and-stick approach.
________________
[1] There I did force the issue a bit. I could have used Notepad++ but I was impressed with how a colleague was using vim and I wanted to use it too, so I resolved to make it my main text editor. Then again that's just more of the same: to learn vim I used vim in my everyday work.
I use the keyboard almost exclusively, and even had colleagues remark on it rather impressed about it I guess (I don't mind the hacker cred, let's be honest here). I never had to force myself, or try silly tricks to drop a habit. I just found myself in situations where either there was no mouse, or it was more convenient to use the keyboard.
First I was forced to use runlevel 3 only, for three months (gpu died and I didn't have any money). Then I had a long commute with only a wimpy netbook with Fedora ...14, I think? With Xmonad on it (because it's damn light). Then I had a job that was done best over a network with powershell and windows remote. Then I had to do a lot of text processing and it was best done using Vim [1]. Then I spent a year on Z/Os where you can use a mouse but the point-and-shoot fields are much more convenient most of the time (except for copy/pasting, strangely). Then I noticed the Windows' 10 tiling desktop manager and there was much rejoicement (it's gotta be a deliberate Xmonad ripoff!). And now of course Windows has a bash shell so there's never any reason to leave the command line. Yay!
On the other hand, it's true that prolongued mouse use hurts my wrist and I am a bit worried that I might get RSI in the long run, so I'm conciously keeping my keyboard habbit fed. I guess what I'm saying is that the main thing you need is a good reason to drop the mouse, rather than a silly carrot-and-stick approach.
________________
[1] There I did force the issue a bit. I could have used Notepad++ but I was impressed with how a colleague was using vim and I wanted to use it too, so I resolved to make it my main text editor. Then again that's just more of the same: to learn vim I used vim in my everyday work.
Anecdotal counterexample: I wanted to learn to use Emacs' keyboard shortcuts for moving the point rather than the arrow keys or page-up / page-down. Leaving aside the question of how useful such a practice is, I only managed to reach my goal once I turned off the arrow keys in Emacs, so that I was forced to "the right thing".
I would argue that it wasn't so silly to do this for my personal use, I'm quite happy with the result.
I would argue that it wasn't so silly to do this for my personal use, I'm quite happy with the result.
Similarly, I've found that getting people to learn how to use vim's movement keys is much easier once I persuade them to add
inoremap <Left> <NOP>
inoremap <Right> <NOP>
inoremap <Up> <NOP>
inoremap <Down> <NOP>
[Edited heavily from initial comment]
That's not just pointless, that's actively harmful. The only thing you achieve in this way is to make it harder for people to see any benefit in learning to use vim, and I question your motivation in doing so.
Vim is useful because it lets you achieve a lot with minimal effort. That it takes some time to learn to use it well is an inevitable side effect of the breadth of control it gives you, and not something to be celebrated in its own right.
There is no One True Way. If you can put that in a shortcut, I strongly urge you to do it, and use it ten times a day until it really sinks in.
That's not just pointless, that's actively harmful. The only thing you achieve in this way is to make it harder for people to see any benefit in learning to use vim, and I question your motivation in doing so.
Vim is useful because it lets you achieve a lot with minimal effort. That it takes some time to learn to use it well is an inevitable side effect of the breadth of control it gives you, and not something to be celebrated in its own right.
There is no One True Way. If you can put that in a shortcut, I strongly urge you to do it, and use it ten times a day until it really sinks in.
[This is a reply to the 'edited heavily' version, I didn't see the original]
> I question your motivation in doing so.
The users in question wanted to get into the habit of using hjkl because you can do things like 23j more easily with them. My motivation was to help them do so.
My suggestion helped them achieve that, and once it had, they removed the config lines again. And thanked me for the help.
> There is no One True Way. If you can put that in a shortcut, I strongly urge you to do it, and use it ten times a day until it really sinks in.
I agree that there's no One True Way. Which is why your a-priori assumption that this couldn't possibly help people when I already know it can seems strange to me; I'm sure it wouldn't help everybody, but the specific people I picked got on fine with it.
> I question your motivation in doing so.
The users in question wanted to get into the habit of using hjkl because you can do things like 23j more easily with them. My motivation was to help them do so.
My suggestion helped them achieve that, and once it had, they removed the config lines again. And thanked me for the help.
> There is no One True Way. If you can put that in a shortcut, I strongly urge you to do it, and use it ten times a day until it really sinks in.
I agree that there's no One True Way. Which is why your a-priori assumption that this couldn't possibly help people when I already know it can seems strange to me; I'm sure it wouldn't help everybody, but the specific people I picked got on fine with it.
Fair point- if it worked for them, it worked for them. I just thought it sounded a bit sadistic, that's all.
For some people it would definitely be sadism. I don't try and convince people I believe that would be true for to try it.
OTOH, watching a partner of mine play with movement commands after they'd internalised hjkl and spending the next half hour navigating around a document while giggling and grinning at me ... definitely demostrates that isn't universal.
I am, honestly, struggling to be polite after you called me making somebody I was in love with happy actively harmful and called my motivations into question rather than considering that there might me more than one way to learn it, but OTOH you're clearly acting in good faith so I hold no animus towards you for your mistake.
OTOH, watching a partner of mine play with movement commands after they'd internalised hjkl and spending the next half hour navigating around a document while giggling and grinning at me ... definitely demostrates that isn't universal.
I am, honestly, struggling to be polite after you called me making somebody I was in love with happy actively harmful and called my motivations into question rather than considering that there might me more than one way to learn it, but OTOH you're clearly acting in good faith so I hold no animus towards you for your mistake.
I am not struggling at all to be polite. There's rarely good reason to be impolite.
I meant actively harmful towards vim's reputation as a useful editor, not to the person you're in love with, whom of course I have not been acquainted with.
Your original comment gave me little context to judge your motivation other than "I told some people to disable their arrow keys". Which I find unnecessary, so I questioned your motivation: literally, I could not understand why you did that.
I meant actively harmful towards vim's reputation as a useful editor, not to the person you're in love with, whom of course I have not been acquainted with.
Your original comment gave me little context to judge your motivation other than "I told some people to disable their arrow keys". Which I find unnecessary, so I questioned your motivation: literally, I could not understand why you did that.
> I just found myself in situations where either there was no mouse, or it was more convenient to use the keyboard.
So it's better to just unplug the mouse then? :)
So it's better to just unplug the mouse then? :)
This is a cute idea. One thing I notice, it cycles the brightness higher every 6.666 seconds regardless of where it began until it reaches 100%. I only notice because I rarely have the brightness at 100% and it was a little disconcerting watching it become more bright over time.
I'm now thinking of how you might make something similar for ratpoison[0]
[0]: http://www.nongnu.org/ratpoison/
I'm now thinking of how you might make something similar for ratpoison[0]
[0]: http://www.nongnu.org/ratpoison/
Looks like someone's already on it: https://github.com/brhs/nomouse/pull/2
I have worked in IT a long time. I learned during the 1980s as a teenager with a Commodore 64 at home and Apple 2 and IBM PCs at high school. This was before the GUI. Everything was text based and shortcut keys.
I remember people claiming that the GUI makes people lazy and dumber. There was an article called "Does the Mac make you stupid?" At the time were they split an English class in two and half used a Mac and the other half a DOS PC. The students who used the Mac had made more errors and got lower scores than those who used the PC. Then the students switched places and computers and those who used the PC had higher scores and the Mac lower scores. It was a big debate and flame war on the BBSes at the time.
http://jan.ucc.nau.edu/~lrm22/technology/stupidmac.html
It was a MacWorld article I scanned to a PDF one time but lost it. I had photocopies from 1990 that I scanned in a few years ago or so.
Keyboard shortcuts can speed up work but to a user who is not computer savvy they need the mouse and GUI.
As a programmer my goal always was to make things easier for the user where they don't have to think to use my UI UX etc that it is intuitive.
I remember people claiming that the GUI makes people lazy and dumber. There was an article called "Does the Mac make you stupid?" At the time were they split an English class in two and half used a Mac and the other half a DOS PC. The students who used the Mac had made more errors and got lower scores than those who used the PC. Then the students switched places and computers and those who used the PC had higher scores and the Mac lower scores. It was a big debate and flame war on the BBSes at the time.
http://jan.ucc.nau.edu/~lrm22/technology/stupidmac.html
It was a MacWorld article I scanned to a PDF one time but lost it. I had photocopies from 1990 that I scanned in a few years ago or so.
Keyboard shortcuts can speed up work but to a user who is not computer savvy they need the mouse and GUI.
As a programmer my goal always was to make things easier for the user where they don't have to think to use my UI UX etc that it is intuitive.
If anyone could find the original Levy article, I would be interested. GUIs create a sort of 'Learned helplessness', where people are deliberately handicapped in their knowledge. It's as if you never learnt to read, and relied on an app which reads text with a speech synthesiser.
I think the whole magazine is here:
https://ia801307.us.archive.org/16/items/mac_MacWorld_9011_N...
That is the PDF version.
https://archive.org/details/mac_MacWorld_9011_November_1990
Page 69 is where it starts, IIRC.
It was very contralesional when it came out, The PC had DOS and the Mac had the GUI before Windows 3.X got very popular.
The irony now is that everyone uses a GUI, is it just the Mac GUI that makes people stupid or is it every GUI out there?
I'm trying to teach friends and family members to fill out forms online. While it is very easy for me, for them it is not so easy. If they want a job, they have to fill out forms on a website.
That is the PDF version.
https://archive.org/details/mac_MacWorld_9011_November_1990
Page 69 is where it starts, IIRC.
It was very contralesional when it came out, The PC had DOS and the Mac had the GUI before Windows 3.X got very popular.
The irony now is that everyone uses a GUI, is it just the Mac GUI that makes people stupid or is it every GUI out there?
I'm trying to teach friends and family members to fill out forms online. While it is very easy for me, for them it is not so easy. If they want a job, they have to fill out forms on a website.
I doesn't say but this is for the Mac.
An unnecessary comment, everyone on HN uses Macs.
/s
/s
A unnecessary comment, everyone on HN used Macs.
/s
/s
A unnecessary comment, everyone on HN uses Macs.
/s
/s
Yeah, it does indeed. Would love to see a solution for reliably starting that thing at system startup. Also, would be nice to be able to pause it for a period of time.
Launchd is your friend here. Good tutorial:
http://www.launchd.info/
Thank you, stranger!
Also, it would be better if the solutions to both of those problems don't involve using a mouse.
Totally, I hate seeing my screen blinking.
Have you found any parts of the OS or your workflow that are really hard without the mouse? I can do keyboard in terminal and text editors, but browsers are so so and Windows RDP is where it all fails the worst for me...
have i got good news for you: https://vimium.github.io/
I use this (well, the equivalent for FF), and it's great, but it doesn't work for every site or button. There are a lot of js buttons that don't get link anchors when you press f. So navigating is still something not possible without a mouse.
I don't know about the Firefox version you're using, but Vimium on Chrome works with `onclick` buttons.
I cheat :) On GNU/Linux (well, X11) I use keynav, a nice little utility that lets you drive the cursor by keyboard. It's often a little clunkier than actual mouse, but you don't have to take your hands off the keyboard and it covers the "I only need to click that one button that somehow isn't possible to hit from the keyboard."
Do I need a compositor for the keynav grid to show up? I've tried prettymuch all the versions off the AUR and none of them show anything.
Strange. I don't think I have a compositor running (i3 wm, not much graphical fluff). Would you mind trying https://github.com/yjftsjthsd-g/keynav and if that doesn't work open an issue? (That's "my" fork, albeit with basically no code from me; I discovered that a number of folks were running separate forks and built a version merging as many as I reasonably could. I think one of them changes the way it renders onscreen and so may have better luck.)
Our tedious accounting/PO system operated via a VM connection to a Win 7 system from a Mac.
Tried this for quite some time now. The one part I find 100x more natural to do with the mouse is handling files and folders.
There's nothing quite like visually doing those things, and no worthwhile shell practice can quite compare.
There's nothing quite like visually doing those things, and no worthwhile shell practice can quite compare.
Interestingly enough, there has been an opposite trend, in software engineering, to have the user rely on the mouse for pretty much everything except typing text. One curious example is Plan 9's text editor called Acme, where to perform certain actions you even have to click more than one mouse button simultaneously, a.k.a.'chords'. (I am not sure how long an average mouse would be able to withstand this kind of abuse.)
I use a mouse with a 12-key thumb pad to move part of the keyboard onto the mouse. Under my thumb are these keys:
F5 Up F2
Left Down Right
Tab Delete Backspace
Enter Space ESC
I think I would sweat bullets if I knew there were an enter key on my mouse, but to each his own.
When I'm web browsing, I never take my hand off the trackpad. I have a suite of custom gestures set up for tab management etc that mean that most of the time I'm not even moving the cursor.
What always bugs me is that finding complete documentation of keyboard shortcuts for whatever program I'm using can be a battle. Better documentation for many apps would be greatly appreciated.
As a side note, I've battled carpal tunnel and tennis elbo for years. One thing that has helped, besides keyboard shourcuts (and many other things) is using an upright mouse on my right and a track pad on my left.
As a side note, I've battled carpal tunnel and tennis elbo for years. One thing that has helped, besides keyboard shourcuts (and many other things) is using an upright mouse on my right and a track pad on my left.
Can't speak to the implementation, but the idea seems pleasantly cheeky, lighthearted, and perhaps even useful.
As for myself, I find the use of the mouse to be its own punishment.
As for myself, I find the use of the mouse to be its own punishment.
A mouse is a terrific thing to use in the right context. Selecting an item among thousands or clicking an arbitrary position (for drawing something or selecting items in a graphical context) is an order of magnitude faster with a mouse.
Navigating a complex webpage with the keyboard is painful even if tab order is perfect.
Starting a command that you have a keyboard shortcut for is perhaps slower with a mouse - so use the keyboard then. But I suspect I do more of the first kind than of the second. And yes I'm a programmer.
Navigating a complex webpage with the keyboard is painful even if tab order is perfect.
Starting a command that you have a keyboard shortcut for is perhaps slower with a mouse - so use the keyboard then. But I suspect I do more of the first kind than of the second. And yes I'm a programmer.
I've found this really useful: http://www.hotkey-eve.com/
For those using X11 who wish to replace keyboard-shortcutless mouse clicks with keystrokes, I humbly suggest my own project SNAM: https://chris.pacejo.net/programs/snam
Oh my. I've needed this so badly. There are so many little things that still obstinately need a mouse even after I've almost completely done away with one. Thank you so much.
My solution is not to connect a monitor to my dev-machine and use ssh/tmux to do most things. It also makes work-from-home easy, as I can loginto my devbox from anywhere. But then it depends on what type of work you are doing, and how you are testing it.
Do you use an IDE on the client (the machine you connect from) and only have sources on the dev machine, or do you work completely in the terminal?
Many people I know just use text editors, no IDEs at all. Modern text editors, whether text-only (vim, emacs) or graphical (Atom, sublime) have plugins to replicate whatever IDE functionality you want anyway.
What? Emacs is graphical!
https://www.gnu.org/software/emacs/tour/
https://www.gnu.org/software/emacs/tour/
Try typing the following into a terminal window, at the prompt:
emacs[deleted]
-nw helps :)
I should have worded my question better. I wanted to know whether he works directly on the dev server over a terminal or only connects to it and uses programs (IDEs, text editors) on the client machine to work on the code.
I usually work on a fairly large project (think of building a complete OS for embedded devices). IDE cannot handle that. My editor of choice is vim, combined with ctags, and some custom plugins. Sometimes when starting a new project from scratch, or writing a new tool, I use sublime (or vscode). I have smb server running on my dev-machine, and can use sublime on client machine.
Do you use a browser (and presumably a mouse) for email, or are you doing that in the console with mutt or pine?
I normally do not use email on my dev machine (use client machine for that). However occasionally I need to run a browser, or GUI app on devbox. I do it via X11. If I am on Windows, I use MobaXterm, which has builtin X11 server. From my macbook, i need to run a seperate x server.
I live in the terminal (and the browser), I use the command line, vim in the terminal. I don't like vimperator, but I do use the VimFX addon for simple jk control of scrolling. And I use the awesomewm tiling window manager.
Some people, when hearing or seeing that, assume that I don't like to use a mouse.
I love my mouse, and it's sitting right there on the couch cushion next to me. Some things, like cut/paste between tmux windows, or between terminal and browser, are just easier with a mouse.
I do try to minimize how much I have to use a mouse, but I use whatever my hand is closest to. Sometimes I scroll the browser with the keyboard, sometimes with the mouse.
I attach zero pride to my use or non-use of the mouse.
Some people, when hearing or seeing that, assume that I don't like to use a mouse.
I love my mouse, and it's sitting right there on the couch cushion next to me. Some things, like cut/paste between tmux windows, or between terminal and browser, are just easier with a mouse.
I do try to minimize how much I have to use a mouse, but I use whatever my hand is closest to. Sometimes I scroll the browser with the keyboard, sometimes with the mouse.
I attach zero pride to my use or non-use of the mouse.
This screen dimming idea seems anoying just the right amount to discourage other kinds of behavior, like cheking emails in the morning or opening a twitter client during some predefined supposedly porductive time window.
Hrm... I think I'll bookmark until April Fools day...
Another strategy: Use a laptop with a terrible touchpad. Being a longtime Macbook user now switching to non-Mac laptops, I just don't find my current Lenovo X1 touchpad to be in the same league. It feels slow and unresponsive. But the keyboard is marvelous. I rarely use my mouse and when I do it's mostly to click items that don't have attached shortcuts.
Glue a push pin on each mouse button, pointy side up.
Cheap, very fast learning guaranteed.
Cheap, very fast learning guaranteed.
Forcing yourself to this approach seems kinda sucking all the fun out of it. I am "fluent" with many hotkeys and love Vim but sometimes I prefer just clicking around...
This needs a Windows build, as Windows users need this the most.
Making you less unproductive to theoretically eventually make you more productive somewhere down the line. Love it!
It should also make a thwump followed by ringing ears sound so it's like getting knocked in the head.
[deleted]
Reminds me of my first day as a programming intern.
All the older devs where blown away by my mouse usage speed.
I guess a skilled shortcut user is faster than a skilled mouse user, but I still can outperform the average shortcut user :D
thanks to years of FPS and RTS games.
All the older devs where blown away by my mouse usage speed.
I guess a skilled shortcut user is faster than a skilled mouse user, but I still can outperform the average shortcut user :D
thanks to years of FPS and RTS games.
Shortcat - https://shortcatapp.com - lets you access nearly all parts of Mac GUI from the keyboard.
Together with the 'Command + Shift + ?' help menu, you don't need a mouse.
There's a lot of good info here: https://github.com/orta/keyboard_shortcuts/blob/master/READM...
Together with the 'Command + Shift + ?' help menu, you don't need a mouse.
There's a lot of good info here: https://github.com/orta/keyboard_shortcuts/blob/master/READM...
I'll second the Shortcat recommendation. Got a license pretty much as soon as I installed and used it (after the trial period, because I can be stingy). Between it and Alfred, I can do most everything I need from the keyboard.
For me, the most obvious/immediate "bang for the buck" is enabling bluetooth when I sit at my desk. If I don't, and use my Macbook from the living room, the distance is just awkward enough, on bad RF interference days, to continuously get the "Connection lost" and "Reconnected" message for the mouse.
For me, the most obvious/immediate "bang for the buck" is enabling bluetooth when I sit at my desk. If I don't, and use my Macbook from the living room, the distance is just awkward enough, on bad RF interference days, to continuously get the "Connection lost" and "Reconnected" message for the mouse.
> nearly all parts of Mac GUI
This is fine for MacOS but it relies on accessibility annotations that most apps I use were missing the last time I used it.
This is fine for MacOS but it relies on accessibility annotations that most apps I use were missing the last time I used it.
Perfect for my inner technopaleoconservative
Maybe I'm just an old-schooler?