8 ms·

"The Editor You Need To Read (At Least) Two Books On To Use Well" Read :help. I haven't read any books on Vim so I'm not sure if there are any good ones, but y

by jcoder 14y ago

"The Editor You Need To Read (At Least) Two Books On To Use Well" Read :help. I haven't read any books on Vim so I'm not sure if there are any good ones, but you most definitely do not "need" to read one. "The point of a mouse is to make arbitrary on screen jumps efficient, and it’s very good at doing that. Don’t you ever think you can beat a mouse. Only in very few edge cases will it even matter." That's kind of ridiculous. When you edit text, your "jumps" are not arbitrary—they have a structure to them, and Vim lets you express your movement within that structure very efficiently in terms of lines, words, sentences, search, etc. With a mouse or trackpad, you have to move away from the keyboard, make a movement to the general area you are targeting, then fine-tune your target down to a space between two characters to insert the cursor. "Pathogen, the first widely used, known, and celebrated path manager making plugin management possible, was released in 2008! Before that, you were encouraged to recursively copy the plugin’s directory into your Vim folder." And before 2008, Sublime Text was nonexistent. What's your point? I have used a plethora of plugin systems, and Vundle is the pinnacle of all of them. Simple to install, remove, and update. "700 hand written lines in my .vimrc, and 45 plugins" I may have found the problem. Learn to use the editor.

msutherl 14y ago
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
  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.
ths 14y ago
Even if the mouse were quicker on average for long jumps, the moving of the hand from mouse to keyboard feels like more of a combo breaker, more distracting. Speed is very important, but equally important is for the editing experience to have a low attention footprint to leave more space for the train of thought behind the changes being made.
- SomeCallMeTim 14y ago
  As someone who uses a keyboard 98% of the time, but who uses a GUI editor and the mouse when it makes sense, I'd say the mouse is useful for several things, and what it IS useful for WILL be faster than what someone can do with a keyboard. The clear win is using a powerful GUI-based editor that has tons of keyboard commands. Bonus points for being on Windows or Linux (i.e., not Mac OS) so you can navigate/BROWSE the menus from the keyboard. I don't know Sublime myself; I'll have to check it out. For some reason I thought it was Mac-only, but I see that it's cross-platform. My editor-of-choice for years has been Visual Slickedit, but I'm not married to it. I just haven't found anything half as good in years of searching. And I keep trying other editors, too, since there are things I find imperfect about it (the scripting language is usable, for instance, but has it's own syntax and quirks).
  - jussij 14y ago
    > there are things I find imperfect about it (the scripting language is usable, for instance, but has it's own syntax and quirks). In terms of scriptable editors, the Zeus editor is scriptable in Lua, Python, TCL or JavaScript, but it is native to Windows: http://www.zeusedit.com/ http://www.zeusedit.com/ Jussi Jumppanen Author: Zeus IDE
    - SomeCallMeTim 14y ago
      Tried Zeus probably 4 years ago. I really have tried a lot of options, but I haven't been back to Zeus after the first try. I can't remember any specifics of what turned me away from it, though the thing that SlickEdit does better than almost everyone else is tagging. I use boost::shared_ptr (and now the C++11 version) a LOT, and so completion is useless in anything that doesn't know how to complete a template class. ctags and its ilk, last time I checked, were worthless in this regard, and I have a vague sense that Zeus relied on those for tagging? Yes, looking at the web site, you're using ctags. Will "shared_ptr<Foo> foo; foo->" autocomplete for members of Foo? SlickEdit also Just Works with tagging. You put the files into a project, and everything is instantly cross-referenced. "Where is Foo::init() used? No, I don't want Blah::init(), just Foo::init()." SlickEdit, at least SOME of the time, can get that right, and with no configuration of external tools. Aside from that, I think one of the greatest drawbacks of Slickedit is that it isn't open source, so when things go wrong I can't just fix it. Slickedit IS cross-platform, at least, with native Linux and Mac OS versions, and that ALSO is important to me. Lua is the Right Answer for scripting, IMO. The rest of the options are actually a liability for me, since it means that if I'm editing someone else's script, I might have to deal with Python, TCL, or JavaScript. I'm rambling now. I feel like I have an "Editor Manifesto" in my head that wants to get out, but I don't have time right now to do it justice. I'll take another look at Zeus when I get a chance, just as I'll take another look at Sublime and the rest. It's been years since I've looked, so I'll take another glance at it.
dlitz 14y ago
You don't even need to read :help right away. All you need to do is: 1. Start the graphical version, i.e. gvim, MacVim, or any version with drop-down menus. 2. Press 'i' to enter "Insert mode". Now just use it like any other text editor. 3. Use the menus. Note the equivalent commands (which are listed in the menus). When you want to use those commands, press ESC to switch to command mode, then enter the commands, then press 'i' again to go back to insert mode. That's it. Modern vim has one of the smoothest learning curves of all software.
- clhodapp 14y ago
  If that's how someone is using Vim, they truly, seriously, should not be using Vim. Sublime really would be better for such a user.
  - ktf 14y ago
    I think his point is that you start out using it that way. Training wheels, sort of, which eventually will come off.
derengel 14y ago
"700 hand written lines in my .vimrc, and 45 plugins" I may have found the problem. Learn to use the editor. This ^^, say no more.
- DelvarWorld 14y ago
  I'm guessing this means you use :Ex instead of nerdtree? I guess you use vimgrep instead of ack.vim or others? I'm guessing you browse your undo tree manually with :undolist ? Can you please write a blog post explaining how to use all of these efficiently? Can you also document how you see inline git changes to the file you're working on? While you're there can you also explain which part of vanilla vim lets you do fuzzy file finding? Learn to use the editor? Are you just editing your visual basic files or what? Edit: if you could also point out which of my vimrc lines are fighting against the vim way and demonstrate that I don't know how to use my editor, that would be super cool.

by jcoder 14y ago

msutherl 14y ago

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

ths 14y ago

Even if the mouse were quicker on average for long jumps, the moving of the hand from mouse to keyboard feels like more of a combo breaker, more distracting. Speed is very important, but equally important is for the editing experience to have a low attention footprint to leave more space for the train of thought behind the changes being made.

SomeCallMeTim 14y ago
As someone who uses a keyboard 98% of the time, but who uses a GUI editor and the mouse when it makes sense, I'd say the mouse is useful for several things, and what it IS useful for WILL be faster than what someone can do with a keyboard. The clear win is using a powerful GUI-based editor that has tons of keyboard commands. Bonus points for being on Windows or Linux (i.e., not Mac OS) so you can navigate/BROWSE the menus from the keyboard. I don't know Sublime myself; I'll have to check it out. For some reason I thought it was Mac-only, but I see that it's cross-platform. My editor-of-choice for years has been Visual Slickedit, but I'm not married to it. I just haven't found anything half as good in years of searching. And I keep trying other editors, too, since there are things I find imperfect about it (the scripting language is usable, for instance, but has it's own syntax and quirks).
- jussij 14y ago
  > there are things I find imperfect about it (the scripting language is usable, for instance, but has it's own syntax and quirks). In terms of scriptable editors, the Zeus editor is scriptable in Lua, Python, TCL or JavaScript, but it is native to Windows: http://www.zeusedit.com/ http://www.zeusedit.com/ Jussi Jumppanen Author: Zeus IDE
  - SomeCallMeTim 14y ago
    Tried Zeus probably 4 years ago. I really have tried a lot of options, but I haven't been back to Zeus after the first try. I can't remember any specifics of what turned me away from it, though the thing that SlickEdit does better than almost everyone else is tagging. I use boost::shared_ptr (and now the C++11 version) a LOT, and so completion is useless in anything that doesn't know how to complete a template class. ctags and its ilk, last time I checked, were worthless in this regard, and I have a vague sense that Zeus relied on those for tagging? Yes, looking at the web site, you're using ctags. Will "shared_ptr<Foo> foo; foo->" autocomplete for members of Foo? SlickEdit also Just Works with tagging. You put the files into a project, and everything is instantly cross-referenced. "Where is Foo::init() used? No, I don't want Blah::init(), just Foo::init()." SlickEdit, at least SOME of the time, can get that right, and with no configuration of external tools. Aside from that, I think one of the greatest drawbacks of Slickedit is that it isn't open source, so when things go wrong I can't just fix it. Slickedit IS cross-platform, at least, with native Linux and Mac OS versions, and that ALSO is important to me. Lua is the Right Answer for scripting, IMO. The rest of the options are actually a liability for me, since it means that if I'm editing someone else's script, I might have to deal with Python, TCL, or JavaScript. I'm rambling now. I feel like I have an "Editor Manifesto" in my head that wants to get out, but I don't have time right now to do it justice. I'll take another look at Zeus when I get a chance, just as I'll take another look at Sublime and the rest. It's been years since I've looked, so I'll take another glance at it.

dlitz 14y ago

You don't even need to read :help right away. All you need to do is: 1. Start the graphical version, i.e. gvim, MacVim, or any version with drop-down menus. 2. Press 'i' to enter "Insert mode". Now just use it like any other text editor. 3. Use the menus. Note the equivalent commands (which are listed in the menus). When you want to use those commands, press ESC to switch to command mode, then enter the commands, then press 'i' again to go back to insert mode. That's it. Modern vim has one of the smoothest learning curves of all software.

clhodapp 14y ago
If that's how someone is using Vim, they truly, seriously, should not be using Vim. Sublime really would be better for such a user.
- ktf 14y ago
  I think his point is that you start out using it that way. Training wheels, sort of, which eventually will come off.

derengel 14y ago

"700 hand written lines in my .vimrc, and 45 plugins" I may have found the problem. Learn to use the editor. This ^^, say no more.

DelvarWorld 14y ago
I'm guessing this means you use :Ex instead of nerdtree? I guess you use vimgrep instead of ack.vim or others? I'm guessing you browse your undo tree manually with :undolist ? Can you please write a blog post explaining how to use all of these efficiently? Can you also document how you see inline git changes to the file you're working on? While you're there can you also explain which part of vanilla vim lets you do fuzzy file finding? Learn to use the editor? Are you just editing your visual basic files or what? Edit: if you could also point out which of my vimrc lines are fighting against the vim way and demonstrate that I don't know how to use my editor, that would be super cool.