6 ms·
Vim has great text navigation features but nothing I can't do with a mouse as fast or faster. With a mouse I can scroll two pages, highlight and replace a funct
by Flankk 16y ago
Vim has great text navigation features but nothing I can't do with a mouse as fast or faster. With a mouse I can scroll two pages, highlight and replace a function in about two seconds. It would take me far longer to do this using keyboard shortcuts.
Most of my time spent coding isn't spent on navigation of text files anyway. Most code is very modular and I switch between text files frequently. In an IDE, you have a navigational tree of your files from which you can find and switch to a different file in about two seconds.
Does anyone have any evidence that vim is actually faster at these two things, and not just hype? If not evidence, at least solutions to the above two problems which you think are faster than using an IDE?
- ozataman 16y agoYou'd be amazed how fast you move around and do edit actions once VIM shortcuts become second nature.
- eterps 16y agoFor me this is hard to understand. Either I haven't seen anyone who is able to 'mouse' as fast as you can. Or you haven't yet seen someone who is really good at Vim.
- masterj 16y agoI didn't understand until I saw one of my professors, who lives in vim, work on some code. It was mind-bending. I can only imagine that when watching me type code (at the time) he must have felt how I feel when I watch my parents use the internet.
- ghotli 16y agoAs a man who lives and breathes vim, the answer to your question is most certainly yes. Watching other people code without mastery of their editor is heartwrenching.
- ez77 16y agoAnyone know of screencasts with keystrokes (I don't know how) that would reveal that mastery?
- rbonvall 16y agohttp://vimcasts.org/ http://vimcasts.org/
- alinajaf 16y agoScreencasts unfortunately won't do it. Learning to touch type (not 'I have my own system' touch-typing, I mean 'Mavis Beacon Teaches Typing' with all ten fingers where they're supposed to be) and then spending a couple of minutes every day learning a new command or two for a few months is more realistic IME.
- jason_tko 16y agoJust went searching on the internet for a vim demo video and found this: http://www.youtube.com/watch?v=QNAXa0W4OFg http://www.youtube.com/watch?v=QNAXa0W4OFg Also, if you have a Mac (or most versions of Linux) you can also access an instant tutorial by typing "vimtutor" at the terminal.
- unoti 16y agoFor those of you looking at this video to get an idea of the power of vim in the hands of a serious user: although this person is using it quickly, he is nowhere near a master. The key to vi is that any time a user is pressing the same key multiple times, there is a faster way. In this video I often see the user using the same keystroke multiple times to get from here to there. Most notable, he routinely does this to get from his cursor position over to a spot later in the line (such as when changing the word "test" which was in quotes), or to get to the end of a section (such as when he was copying then changing the body of a function). If you're a vi user or an aspiring vi user that wants to get faster, then start consciously looking for times that you're pressing the same key more than about twice. Each of those times is almost certainly an opportunity to get faster. So in particular from watching the above video, these are two shortcuts that I use all the time that the video maker did not use. Let's say you have a line of text like: Img.save('roberto.png') and you want to change it to x.png. If your cursor is at the start of the line, you would never arrow over there. You would type fr (find r, which would move your cursor to the r in Roberto). Then you would type "ct.x" which means change until we get to the period and replace it with the letter x. It sounds complex, but after a while you just do it without thinking, and it's faster to type 5 keystrokes with 2 hands than a bunch of repeated keystrokes with one hand. Similarly, the } and { keys should be used to navigate to the next or previous blank line, which could have been used in this video to change the body of those functions in a couple of keystrokes instead of the arrowing around and highlighting we were seeing. I'm not trying to pick apart the video, the person is clearly fast and effective. The point is just that vi gives you the flexibility to always get faster if that's what you're into.
- eggoa 16y agoWe can shave another keystroke off your example. Instead of "ct.x", "cwx".
- gurraman 16y agoFor me it's about convenience rather than speed; I find myself switching between navigating and editing a lot, not having to switch between the keyboard and the mouse is very convenient. That said, I think I'd perform your example-interaction faster with the keyboard and my knowledge of the shortcuts in Vim. It's probably due to accuracy (with a Vim movement command I know exactly what is targeted -- no need to aim with the mouse). Merry Christmas!
- bad_user 16y agoWith a mouse I can scroll two pages, highlight and replace a function in about two seconds I really don't believe you. Scrolling itself takes 2 seconds minimum. You also haven't mentioned the time it takes to open that second file (to open a parallel window with another file costs me 1 keystroke to open the window, another keystroke to invoke "find", and 4-5 keystrokes to type a keyword). In Emacs scrolling, highlighting and cut/pasting that function does take me at most 2 seconds (the total time): mostly because I don't have to scroll, almost never, as I jump through the file by doing searches, which in Emacs are really cheap and intuitive, with great shortcuts. Highlighting is also a lot faster for me: You have to drag down the mouse cursor, while holding the left button, being careful to not select too much or less. That alone can take 2 seconds. What I do is to get to the start of the block (again, shortcuts for jumping in Emacs are great), mark the start of a selection, then jump again (here I don't even have to search, since I can jump to the closing bracket). So highlighting a block costs ~ 6 keystrokes (including search), and takes me less then a second because these shortcuts are already hardwired. Also, when copy/pasting text Emacs remembers everything you ever copied in your current session (the kill-ring); if you copied something a couple of minutes ago, there's no reason to return and copy it again. This and other niceties like ... being able to UNDO anything, even previous UNDO operations, or being able to UNDO operations only in a selected region of text, make it the ultimate text editor for me. Also, working with windows in Emacs could use some work, but buffers are great.
- swah 16y agoWhat could be easier when working with windows?
- jarin 16y agoMaybe all of the hardcore vim purists will hate me, but I use the mouse a pretty good amount when I'm using vim. I'd say I do about 70% navigation with the keyboard and 30% with the mouse (mostly scrolling). Also, I had to post the famous quote that "emacs is a decent operating system, lacking only a good editor".
- ths 16y ago"emacs is a decent operating system, lacking only a good editor" viper/vimpulse solves this quite neatly. I find the mix of emacs with viper+vimpulse to be the best of both worlds: The efficiency of vim when doing fine-grained text manipulation and navigation, and the completeness of emacs for integrating my workflow (running shell processes, switching buffers and finding files with the built-in fuzzy matching ido-mode). It's just so much better to have the terminal in a split window, interchangeable with code buffers, than having to alt-tab all the time. Emacs brings vi to the whole workflow, in my experience. All the little things, like selecting and yanking text to and from shell buffers (all with vim keybindings), just make it feel good. Also, the indentation is great, keyboard macros are much better (you can record commands other than simple keystrokes, e.g. searching) and the language modes just seem to understand their subject languages more "deeply" somehow. vim and emacs + viper/vimpulse are both programming environments that implement vi's modular editing philosophy. It's the vi editing model that I couldn't possibly leave behind me, not vim. I might even be able to survive a modern "IDE" were I able to use well-implemented vi/vim keybindings :)
- riffraff 16y agoby function you mean a function call? two pages down, and replace it's about 8 keystrokes (ctrl-f-f to get to second page, say /<first-two-chars> to get to the function, cw to change it) does that take you more than two seconds? Also, you'd probably just do search instead of moving down two pages, and then replace (/<first-three-chars>cw). I'm no vim power user though, so I can't say if there is a better way, but it is faster for me. I believe in full featured ides (because of features like integrated debuggers, refactorings) but not because of the mouse, so even if for example eclipse has a file tree, I usually open a class by shortcut+<start typing classname>enter, isn't that faster than navigating a tree?
- gnosis 16y agoThe faster way would be if you used ctags and had your cursor already on the function name. Then, simply typing: CONTROL-] would take you to the function definition (wherever it was, in the same file or in a different file), and: cw would change it. Three keystrokes in total. There's no way a mouse user could do better. Especially as he'd need to type "c" anyway, to start changing the name of the function after he'd selected it with the mouse. So the difference would really be in two keystrokes vs moving your hand to the mouse, scrolling down, using some error-prone and slow way of finding the function name visually, followed by a selection of the function name with the mouse. A touch typist should easily be able to type those two keystrokes in the time it would take to simply move one's hand from the keyboard to the mouse. So however long it takes to perform the rest of the needed operations to find and select the function name by mouse along with moving one's hand back from the mouse to the keyboard would be time wasted in comparison to the keyboard method. Time that could be more productively used in continuing to edit something else. Now multiply that time waste by 50 or 100 times you need to do that per day, the hundreds of days you spend editing per year, and the decades you spend editing in your life. And that's not to mention the more complex editing tasks that are simply impossible to do with the mouse (without breaking out the virtual keyboard that you'd need to click on with the mouse, which would be a completely ridiculous way to edit if you had a real keyboard in front of you and were capable of using it).