7 ms·

As somebody who recently switched from Vim to SublimeText, I agree and disagree with much in the article, but the point about the mouse is interesting. For yea

As somebody who recently switched from Vim to SublimeText, I agree and disagree with much in the article, but the point about the mouse is interesting. For years I believed that eschewing the mouse was speeding me up. But I recently had the pleasure of working with a fine gentleman, and a SublimeText user, who is an absolute fiend with the mouse. He has considerably more development experience than I, so it is not an unbiased comparison, but I believe his raw editing speed was a bit faster. This confirmed my suspicion, originally triggered by reading about the Acme[1][2] editor in Plan9, that such a workflow can be quite efficient. [1] http://en.wikipedia.org/wiki/Acme_(text_editor) http://en.wikipedia.org/wiki/Acme_(text_editor) [2] http://www.youtube.com/watch?v=Pydckb9ZU8Y http://www.youtube.com/watch?v=Pydckb9ZU8Y

catenate 14y ago
In my experience (11 years with Emacs, then 8 years with Wily/Acme-SAC/Acme) using the mouse is much more efficient than typing to move the cursor and select text. Acme takes it a step further by binding cut and paste to mouse chords. Guide files are the big win, though, since I edit and reissue commands (highlight and middle-click) instead of retyping them.
- davorb 14y ago
  Do you use C-r/C-s to move around? That's what I do and I think that using the keyboard is a bit faster. The difference is probably negligible, though.
  - jeremiep 14y ago
    There's also ace-jump-mode to quickly move the point in the visible area of the buffer. It can be a bit faster than C-r/C-s sometimes.
- gnuvince 14y ago
  I tried Acme, and though it had some good ideas, I found that the execution was sometimes poor. I especially disliked that so much emphasis was put on the mouse with no way to fall back to the keyboard.
  - catenate 14y ago
    Extra ways to do the same thing is the enemy of simplicity and orthogonality. A major reason Plan 9 and Inferno are so small (the plan9port layer is 51.7MB source, the Inferno VM OS is 51.6MB source), and easier to grasp in one person's mind, is that the old Unix guys ruthlessly stripped out extra ways of getting things done, and made sure they ways that were left played well with each other. I keep a much smaller working set of unixy information in my head, while working daily with Acme and Inferno's userland, than I had to using Solaris or Linux and vi or Emacs. The way I work in Acme, commands (whether built-in or my own) are presented in front of me for execution, so I edit and highlight and execute them. I don't take time out of thinking about code to think about the magical key combinations that do whatever. So it's more muscle memory to commands on the screen and sight recognition than remembering keystrokes. I do recall that many of my Emacs commands were muscle memory, but the more I wanted to use, the harder it was to remember them all. I lost them quickly when I stopped using emacs. Years from now the commands I used to manipulate files in a given directory will still be there in the guide file, waiting for me to run them without error. (I help this along by directory-specific logging of interesting commands.) I was especially happy to get away from the hundreds of extra options in the GNU tools userland, which made entire other tools obsolete (e.g., sort -u obsoletes uniq, except when you need to uniq -c or uniq -d). All these options are the enemy of clarity in code, so you can more confidently write portable, straightforward scripts, go back to them later and actually read them.
    - gnuvince 14y ago
      > Extra ways to do the same thing is the enemy of simplicity and orthogonality. Adding support for moving the cursor with the arrow keys would not involve a very high amount of complexity. I found that Acme required me too much to just let Rob Pike dictate how I should work rather than providing a tool that I can customize to my habits and my needs.
      - catenate 14y ago
        Hey, don't get me wrong, I'm as turned off by Rob Pike's dismissal of everything not in his vision as the next 9fan or gonut. It took me forever to really efficiently use Acme, and no generics means no Go for me, since it's ridiculous to not have map, fold, and filter at your disposal once you've used it in other languages like Haskell, Python, even Perl or the shell. But what's great about his tools is that if you do let them creep into you, your daily practice gets much better because the weight of the environment doesn't slow you down so much.
gnuvince 14y ago
I believe it depends on the kind of movement you need to do. If you need to go to an arbitrary point in the screen, I agree. However, if you are on a line and want to go to the end of the line, is it not easier to press the `End` key (or C-e for Emacs users, $ for Vim users) than take the mouse and aim it at the end of the current line? Depending on the task at hand, using the keyboard may or may not be faster.
crucialfelix 14y ago
The mouse and scroll wheel work just fine in my VIM in the terminal. I use whichever one is closest at hand (literally). In any case we should soon have eyeball tracking to move around. and/or leap motion. also when can I simply shout at the screen and get it to do my bidding?
johncoltrane 14y ago
The "problem" with the mouse is Fitt's Law. It is easy to use the mouse to hit large targets but, as the size of the target decreases, the duration and complexity of the task augments. Since we, as programmers, deal with very small targets, using the mouse is not the most efficient way to go. Some editors allow us to move very quickly to the next opening bracket on the line (Vim's f{ for example) while most editors can't help beyond a certain point (usually the OS's word-by-word jumps). If the only means you have to reach that opening bracket is a dozen presses on the right arrow or the mouse… well, the mouse may have its chances. When you can do f{ the mouse is simply useless. Also, the motion of the mouse is non-linear: you have typically a fast startup followed by a progressive slowdown until you reach your target. That slowdown happens because the fast startup was done in the general direction of the target and must be adjusted a few times to hit the target accurately. Another thing to factor is how often you use the mouse in your workflow. When I do mouse-y tasks (Photoshop, browsing…), the mouse is my primary way too interact with my programs. My left hand is available for hitting modifiers or changing tools while my right hand is almost always on the mouse. In that context, I never loose the pointer and the mouse. Changing from task A to task B with the mouse is easy and costless. When I do keyboard-y tasks, the keyboard is my primary means of interaction. I can spend a lot of time typing stuff, moving around… without touching the mouse. When I want to use the mouse I usually don't really know exactly where it is — that's a first problem — then, when I grab it, I don't know where the cursor is — second problem — which makes the initial targeting slow and error prone. Once the first steps are dealt with, the limitations in Fitt's law apply. That's why the mouse is frowned upon among people who use primarily the keyboard.
- Shorel 14y ago
  I do always set up my mouse to have no acceleration. You are right about it. However, how many people who frowns mouse use knows that you can select a word by double clicking on it, or that you can extend a selection using shift+click, or that nothing scrolls a document as fast as the scrollbar or minimap?
  - johncoltrane 14y ago
    Those are part of the first things you learn in your first hour in front of a computer. I think that my comment is clear on my position on that "mouse debate": the mouse is an effective interaction device in more than many contexts but there's at least one context where using the mouse is not the most effective thing to do. Again, the problem is not the mouse itself but the cost of constently switching between it and the keyboard.

catenate 14y ago

In my experience (11 years with Emacs, then 8 years with Wily/Acme-SAC/Acme) using the mouse is much more efficient than typing to move the cursor and select text. Acme takes it a step further by binding cut and paste to mouse chords. Guide files are the big win, though, since I edit and reissue commands (highlight and middle-click) instead of retyping them.

davorb 14y ago
Do you use C-r/C-s to move around? That's what I do and I think that using the keyboard is a bit faster. The difference is probably negligible, though.
- jeremiep 14y ago
  There's also ace-jump-mode to quickly move the point in the visible area of the buffer. It can be a bit faster than C-r/C-s sometimes.
gnuvince 14y ago
I tried Acme, and though it had some good ideas, I found that the execution was sometimes poor. I especially disliked that so much emphasis was put on the mouse with no way to fall back to the keyboard.
- catenate 14y ago
  Extra ways to do the same thing is the enemy of simplicity and orthogonality. A major reason Plan 9 and Inferno are so small (the plan9port layer is 51.7MB source, the Inferno VM OS is 51.6MB source), and easier to grasp in one person's mind, is that the old Unix guys ruthlessly stripped out extra ways of getting things done, and made sure they ways that were left played well with each other. I keep a much smaller working set of unixy information in my head, while working daily with Acme and Inferno's userland, than I had to using Solaris or Linux and vi or Emacs. The way I work in Acme, commands (whether built-in or my own) are presented in front of me for execution, so I edit and highlight and execute them. I don't take time out of thinking about code to think about the magical key combinations that do whatever. So it's more muscle memory to commands on the screen and sight recognition than remembering keystrokes. I do recall that many of my Emacs commands were muscle memory, but the more I wanted to use, the harder it was to remember them all. I lost them quickly when I stopped using emacs. Years from now the commands I used to manipulate files in a given directory will still be there in the guide file, waiting for me to run them without error. (I help this along by directory-specific logging of interesting commands.) I was especially happy to get away from the hundreds of extra options in the GNU tools userland, which made entire other tools obsolete (e.g., sort -u obsoletes uniq, except when you need to uniq -c or uniq -d). All these options are the enemy of clarity in code, so you can more confidently write portable, straightforward scripts, go back to them later and actually read them.
  - gnuvince 14y ago
    > Extra ways to do the same thing is the enemy of simplicity and orthogonality. Adding support for moving the cursor with the arrow keys would not involve a very high amount of complexity. I found that Acme required me too much to just let Rob Pike dictate how I should work rather than providing a tool that I can customize to my habits and my needs.
    - catenate 14y ago
      Hey, don't get me wrong, I'm as turned off by Rob Pike's dismissal of everything not in his vision as the next 9fan or gonut. It took me forever to really efficiently use Acme, and no generics means no Go for me, since it's ridiculous to not have map, fold, and filter at your disposal once you've used it in other languages like Haskell, Python, even Perl or the shell. But what's great about his tools is that if you do let them creep into you, your daily practice gets much better because the weight of the environment doesn't slow you down so much.

gnuvince 14y ago

I believe it depends on the kind of movement you need to do. If you need to go to an arbitrary point in the screen, I agree. However, if you are on a line and want to go to the end of the line, is it not easier to press the `End` key (or C-e for Emacs users, $ for Vim users) than take the mouse and aim it at the end of the current line? Depending on the task at hand, using the keyboard may or may not be faster.

crucialfelix 14y ago

The mouse and scroll wheel work just fine in my VIM in the terminal. I use whichever one is closest at hand (literally). In any case we should soon have eyeball tracking to move around. and/or leap motion. also when can I simply shout at the screen and get it to do my bidding?

johncoltrane 14y ago

The "problem" with the mouse is Fitt's Law. It is easy to use the mouse to hit large targets but, as the size of the target decreases, the duration and complexity of the task augments. Since we, as programmers, deal with very small targets, using the mouse is not the most efficient way to go. Some editors allow us to move very quickly to the next opening bracket on the line (Vim's f{ for example) while most editors can't help beyond a certain point (usually the OS's word-by-word jumps). If the only means you have to reach that opening bracket is a dozen presses on the right arrow or the mouse… well, the mouse may have its chances. When you can do f{ the mouse is simply useless. Also, the motion of the mouse is non-linear: you have typically a fast startup followed by a progressive slowdown until you reach your target. That slowdown happens because the fast startup was done in the general direction of the target and must be adjusted a few times to hit the target accurately. Another thing to factor is how often you use the mouse in your workflow. When I do mouse-y tasks (Photoshop, browsing…), the mouse is my primary way too interact with my programs. My left hand is available for hitting modifiers or changing tools while my right hand is almost always on the mouse. In that context, I never loose the pointer and the mouse. Changing from task A to task B with the mouse is easy and costless. When I do keyboard-y tasks, the keyboard is my primary means of interaction. I can spend a lot of time typing stuff, moving around… without touching the mouse. When I want to use the mouse I usually don't really know exactly where it is — that's a first problem — then, when I grab it, I don't know where the cursor is — second problem — which makes the initial targeting slow and error prone. Once the first steps are dealt with, the limitations in Fitt's law apply. That's why the mouse is frowned upon among people who use primarily the keyboard.

Shorel 14y ago
I do always set up my mouse to have no acceleration. You are right about it. However, how many people who frowns mouse use knows that you can select a word by double clicking on it, or that you can extend a selection using shift+click, or that nothing scrolls a document as fast as the scrollbar or minimap?
- johncoltrane 14y ago
  Those are part of the first things you learn in your first hour in front of a computer. I think that my comment is clear on my position on that "mouse debate": the mouse is an effective interaction device in more than many contexts but there's at least one context where using the mouse is not the most effective thing to do. Again, the problem is not the mouse itself but the cost of constently switching between it and the keyboard.