Ask HN: Can you show me how fast coding is in vim?

[arkaeologic]

I have tried to learn vim, and I am on the fence about which editor to use. I have tried Atom, Eclipse, Emacs, etc. VSCode just came out and Facebook has its Nuclide editor on the shelf. People hold vim as a pinnacle of editing technology.

Can you show me with a short screencast why vim is superior? And, why it is worth spending the time to learn, not only mentally and visually, but also mechanically with my hands.

Thanks.

[capote]

You first need to learn the differences between these editors, and determine what you expect from an editor.

It's pointless to compare vim, atom, and eclipse in the same thought process because they're completely different tools for different tasks.

> ... as to why vim is superior

Vim is not superior categorically. If you expect your editor to autocomplete Java code for you and fill in imports and look up methods for you, and have extra features that aren't even connected to editing, Eclipse is tremendously better. But Eclipse is a different tool. It's a full IDE.

Atom is a gui-based editor.

Vim is a cli-based editor.

I've been seeing people left and right comparing editors as if there were some definitive lockdown about to happen that binds you to a single editor. Use whatever you like and what gets your job done. You can also use more than one for more than one task.

I use vim when I'm editing files via ssh remotely, Sublime when I'm editing local files, and VS Pro when I'm working with .NET at work, because these are, respectively, my tools of choice for these tasks.

None are "better" or "worse". They're just different.

[capote]

Now, all that said, I do have a story about speed with Vim:

When I was in high school, I bragged to my dad about typing something like 110 words per minute. He said… that's nice; I can type 1100 words per minute. Incredulously, I asked him to show me. He fired up his vim setup, opened a few files, started a new one, and sure enough in under 60 seconds he had a ~1100 "word" Sybase stored procedure (or something) written.

Of course he didn't literally type all of it. Of course it was a loooot of copy pasta, and the whole thing was tongue-in-cheek. But it was a good example of what you can do with Vim given the right scenario.

[elcapitan]

With a ctrl-a, ctrl-c, ctrl-v loop you can "type" exponentially fast in any editor, I guess.

[capote]

It was a little more complex than that because the new stored procedure was indeed new and contained different structure, as far as I remember. ;) but yeah, copy pasting definitely takes a bit of the elegance out of it.

Most of what was demonstrated was Vim's superior capacity for jumping around to the correct place in your file precisely and quickly, which doing with a mouse is a nightmare.

[throwaway2016a]

Vim has a lot of key commands to quickly working with blocks of text so it is a bit more nuanced than that.

For example, to copy 3 lines from the cursor position and paste them 5 lines earlier:

3Y :-5 p

(and there are faster ways, some people are wizards)

I also do relative numbering in my vim (I have the current line labelled as 0, the line above it -1, etc) so that I can move around relative to the cursor without having to count lines. You can also do absolute numbering but I find that tedious when you have large files.

[elcapitan]

I know, I've been using vim pretty exclusively for the last 15 years or so.

[noobermin]

Limited of course by cache reads for very large blocks of text.

[twunde]

Fully agree. Each type of editor excels at different use-cases.

vim/emacs. Once you get up to speed, you can type or move around faster than with other editors. The main reason to use these are because you're already spending most of your time in the terminal because you're a) working in an ecosystem like rails where most of the tooling is run from the terminal b) doing sysadmin tasks like editing config files, running ansible or otherwise writing code over ssh. That's the sweet spot. Once you become comfortable there are ways to extend the editors to basically give them ide-like functionality.

Gui-based text editors like Atom, Notepad++, etc. These are the simplest editors to get up and running and have a low level of bloat. You usually don't need to spend time waiting for it to load whereas most IDEs take 1-5 minutes to load up fully. The main reason to use these is ease of use. If you don't need the complexity of vim or an ide, use this.

IDEs work best when you are dealing with large codebases, especially if you're not familiar with the codebase or the available functions. I personally maintain ~600k lines of mostly undocumented code at work. It uses a custom framework and was contributed to by dozens of developers. There an IDE is probably the best choice because it will catch errors (made by you or past developers), it will autocomplete function names and best of all, there is a jump to definition feature so you can quickly trace through code paths. After two years of working here I can use vim without too much of a dropoff

[capote]

Whenever someone gets too preachy about Vim or Emacs, I always imagine them trying to work on a full .NET project with Vim. Is this even possible? I can't imagine.

[throwaway2016a]

Just pointing out... autocomplete of Java code is completely doable in Vim. As are file trees and many things that IDEs offer.

With that said, there are also plugins for many editors that make vim commands work in them. Which is a nice compromise if you like GUIs.

[capote]

It's just not the same as with Eclipse. I'm not sure what it's called or if it has a name, but the Eclipse equivalent to VS Pro's IntelliSense, in which it's actually aware of code that you've previously written in other files or third party libraries, and it pops up as a little list next to what you're typing--is it possible to have that level of functionality in Vim?

It's the actual awareness of code you've previously written, the detection of possible issues before you compile--IDEs tend to read your code with you and help out a lot in many more ways... I suppose it's not "autocompletion" but I was hoping to successfully use that as an umbrella term.

[throwaway2016a]

Yeah, it's probably not as good but AFIAK it does know about your other class files and things like that so for most people it will get the job done.

Take it with a grain of salt, though. There are 3 (that I can find) Java auto-complete plugins for Vim and I have no idea if any of them are good. (I don't develop in Java often and when I do it's trivial code so I haven't had a chance to try them)

[capote]

Yeah, to be honest, I don't know much about Java and Java tools either; I'm just going by what I remember from school. I just assumed that Eclipse has similar functionality to VS Pro, which I know we couldn't replace with Vim.

[lsiebert]

Eclim is headless eclipse autocomplete in vim, so you get best of both worlds, pretty much.

[fifnir]

this: https://github.com/henrikpersson/rsub

changed my life, now when I'm in ssh I can just "rsub this.txt" and it pops up in my currently running sublime window !

[capote]

Neat—I've always known in the back of my mind something like this is possible but I just never looked around.

[shadeless]

I've seen a lot of comments saying this answer on stackoverflow opened their eyes to using Vim: http://stackoverflow.com/questions/1218390/what-is-your-most...

[shadeless]

Also, from my own experience I can't really tell if I'm actually typing/coding faster faster since switching to Vim/Spacemacs, but I did notice a significant change in achieving and staying in a state of flow. Not having to touch the mouse or consider how a text transformation should be done (but just doing it mechanically) helps me stay in the zone. YMMV.

[throwaway2016a]

That article is incredible. I use vim pretty much exclusively and this reminded me of some stuff I don't use enough.

[krat0sprakhar]

A ton of hyperbole, but an enjoyable read - https://www.norfolkwinters.com/vim-creep/

Interviews of vim programmers - http://howivim.com/

Gary Bernhardt's screencast on - https://www.destroyallsoftware.com/screencasts

[vvanders]

Good article, all the comments following are pretty great as well.

[jbob2000]

Check out this video game: http://vim-adventures.com/

Play through the first few levels and it becomes apparent why people like vim; you can move around a text file incredibly quickly, a mouse is slow and dumb by comparison.

[some1else]

I think Derek Wyatt's screencasts[1] are precisely what you're looking for. You won't be able to help but pick up a few things along the way.

1: https://vimeo.com/user1690209

[nekomancer]

Somewhat related, I started out using Emacs and have since moved to using vim. I'm at the point where I feel semi-proficient in it, and I've started playing around with .vimrc, pathogen-based addons, as well as other stuff like ctags a bit, and based on my experience so far this extensibility and customization is what makes the text editor so powerful compared to other ones (although I can't really speak for Emacs since I didn't get as far with it).

That being said, I've recently started picking up an interest in lisp (currently slowly making my way through sicp), and I've seen indications that Emacs is somehow more suited to lisp development than vim. As a result, I've actually been considering switching back again, despite emacs pinky, although I'm still on the fence about this.

If anybody here has some knowledge about what Emacs offers in terms of lisp development that vim doesn't (or vice versa) and/or has some good references, I would be very interested to know.

[mcbuilder]

Try Spacemacs out! https://github.com/syl20bnr/spacemacs

The beauty of emacs is that it is extremely customizable. spacemacs features a full fledged vim emulation mode that does a great job of feeling like vim.

As far as lisp development goes, the reason for emacs being a "better" environment is that it is implemented in a flavour of lisp, so you see a lot of great packages (paredit/smartparens, SLIME, to name a few) built with lisp in mind. Plus you will be editing your config file in lisp.

[superskierpat]

Though vim (and neovim) has the same plugins these days. I've been using paredit and it works great.

[yodsanklai]

The bottleneck in programming isn't typing. It doesn't really matter what editor you use.

[joeld42]

Casey switched to a modal editor for the handmade hero livestream (because of RSI issues). It's not vim, but it's similar since it's modal. He's only just switched about a month ago, but he's already pretty quick, though not as fast as he was with emacs. You can compare old episodes to current ones to see someone editing with a vim-like editor and emacs one.

I've personally gone through phases of using vim, emacs, notepad++, Visual Studio, and (currently) SublimeText and xcode. My opinion is that the editor is never the "bottleneck" with programming speed, so just use whatever is the most comfortable for you. One nice thing about vi/vim is that some variant of it is installed almost everywhere so you're always likely to have a usable editor available if you learn it.

[bing_dai]

I would recommend Shortcut Foo (https://www.shortcutfoo.com/app) to people who want to learn vim. It offers shortcut training (pun-intended) to many other editors (Sublime, Eclipse, etc.) and languages too.

[pvinis]

Where is the pun?

[noobie]

I think it's the fact that it's a training for shortcuts and the training in itself is a shortcut (i.e. short, concise etc.)

[capote]

I'm not sure if the pun jury would agree that that's actually a pun.

[noobie]

Indeed. But fingers crossed until they reach a Virdict. (I'll show myself out hehe)

[capote]

I hope the punishment isn't too harsh.

[pvinis]

Thanks for clarifying. I didn't read it in that way.

[B1FF_PSUVM]

In this topic: people worrying about how fast they can make mistakes.

[falcolas]

> Can you show me how fast coding is in vim?

The tongue in cheek answer: My ability to code quickly is held back by my ability to create code structures in my mind, not type code into an editor.

I appreciate vim not because it's faster, but because I don't have to think about using a mouse, and I can just have a conversation with the editor.

"Correct inside these parenthesis" ci(

"Insert the text 'func Something() error {'"

"Delete three lines and paste them above the current line" 3ddP

"Goto the definition" gd

"Go back" C-o

"Write to disk and quit" :wq

[Ologn]

You don't have to choose one. I use vi a lot, but when I want to do something complicated I often switch to emacs.

It is easy for me, and not a lot of typing. I log on a server, and type vi program.py. Now I am in normal mode at the top of the file. If I want to go to line 80 I type 8-0-return. If I want to search for a list called dataList below that I type /dataList and return. If I want to go to the bottom of the file I type G. If I want to go back to the top of the file I type 1G. It is economic with how much typing you need to do. It loads up quickly. It also uses the same commands as ed in case you're on a dumb terminal, although that tends to be rare nowadays.

If I'm doing a lot of multi-window stuff, or cutting and pasting from the middle of a line to the middle of another line 3000 lines down or something complex I use Emacs. For example, emacs has a command 'keep-lines' where only lines matching a regex get kept (or flush-lines where all lines matching a regex get deleted). Vi can do more complex stuff but I usually just switch to emacs when things get complicated.

Speaking of speed - if you look at the old e-mails and Usenet posts and such from Bill Joy on the net, you may notice he did not capitalize any letters when he wrote. That saved him the time of having to hit the shift key.

[justizin]

If you work with UNIX / Linux servers a lot, or really at all, it's a good idea to be comfortable with basic vi usage - vim being Vi IMproved, with some features that we've all become comfortable with.

You will find a version of vi on almost any UNIX-ish system you're likely to find running. It's an incredibly robust and battle-tested editor which can help you out of tight situations.

Nano isn't so bad and is fairly common now, but its' predecessor, Pico, was absolutely terrible for editing code. Pico was originally the editor bundled with the Pine e-mail client, and it had a nasty habit of chopping lines of text at 80 characters wide. I once used Pico to edit a hundreds-of-lines-long apache config, bungled the whole thing, and had to manually reconstruct it with vi.

At the time, I was a fairly new employee in my first tech job as support for a Linux distributor in the 90s and our build engineer fairly quickly informed me that it was time I learn vi.

Any system with vim installed on it - including a fresh Mac - will have vimtutor, which I highly recommend everyone spend a half hour with. When I taught Linux admin courses, I had everyone run through this at lunch on the first day to help them avoid the professional embarrassment I had. ;)

[Edit: and I second what everyone else says about it not necessarily being a supreme development experience. I use a Mac with, over the years, TextMate, Sublime, Light Table, and now Atom. Some people make a convincing argument that Emacs is a supreme dev environment, but I've never quite picked it up]

[Zekio]

Only people who can save & exit vim holds it as the pinnacle of editing technology. :) the rest of us can't save files in it

[Mikeb85]

Use GVim if you want a gentle introduction. It has GUI buttons for all the basic functions, but key shortcuts still work.

[dsmithatx]

:wq <filenamegoeshere>

[dionidium]

The problem uninitiated users have with vim is that it's modal. It's not that they can't type :wq; it's that they don't know where or how to type it or even, conceptually, what the heck is going on when they type that command and it shows up as text.

I'm a long-time vim user, but it's at least worth confronting the criticisms head on (even if this one is a bit tired).

[ljk]

or :x

[allan_s]

or ZZ

[WorldMaker]

Or Ctrl+S, Ctrl+W in most GUI environments (gVim, neovim)

[pgbovine]

Vim user for ~10 years ... I find Vim more productive for writing prose than coding, since oftentimes the limiting factor when coding isn't pure typing/editing speed. And, as other posters have mentioned, good IDEs nowadays have a lot of integrated support for the entire software lifecycle and not just for pounding out code as fast as possible.

[dsmithatx]

I don't have time to make a screencast but, I don't see a huge difference between VIM/Emacs to be honest. Most devs seem to like Emacs more for the easy complexity I suppose.

For modern development I wouldn't compare vim (a text editor) to Eclipse (an IDE). I'd say learn vim if you think you might ever find yourself in a shell needing to do things. No Xwindows and maybe not even emacs. I personally use vim for everything I do but, that's because I've used it for 21 years now. The second reason is I develop by always taking the easiest path (kiss theory) and generally don't need an IDE for most things. The third reason is that I started developing carpel tunnel in my right hand using the mouse and decided to not use a mouse as much as possible.

[organsnyder]

Just about every IDE has a vim-mode plugin available. While they're not perfect, they give you much of the efficiency while not having to give up the trappings of an IDE.

I also have struggled with mouse-related RSI. Switching to trackballs helped a ton for me.

[mosdave]

this. vsvim definitely improved my daytime life.

[zzalpha]

Honestly, I switched because of RSI. Other editors require a lot of chording. Hell, just look up the term "emacs finger". Some might claim that's because of poor control key positioning, but repurposing capslock is frequently not an option and doesn't totally alleviate the problem.

Switching to Vim completely eliminated those issues for me.

As a happy bonus I gained access to a lot of Vim tricks... Normal mode is basically a weird programming language, which makes it enormously powerful, particularly for repetitive tasks. And Vim macros are magical as a consequence.

Which is why when using VS or IntelliJ I adopt Vim emulation plugin of some kind. None are perfect but most are sufficient to allow me to continue to use my Vim muscle memory in more integrated environments.

[soyiuz]

I would suggest that Vim is about more than speed, it is about flow. Think about the difference between ctrl-c and navigating to the menu to copy with your mouse. One just feels more fluid and requires less thinking. Games use extensive keybindings for the same reason.

Vim in particular is a philosophy of keybindings. It has a syntax and a logic to it. For example `daw` will delete a word. To delete a sentence you would `das`. Guess what you would use to delete a paragraph? Once you "grock" vim logic you can perform more complex actions without much cognitive overhead and with your fingers on the home row. Writing in Vim gives me a feeling of mastery and fluidity with the machine I have not felt since my competitive gaming days.

[capote]

> For example `daw` will delete a word. To delete a sentence you would `das`.

Huh. I use 'dw' and 'dl'. Why the extra key?

[shadeless]

Using 'dw' deletes from the cursor until the end of the word.

Using 'daw' deletes the whole word "around" the cursor (hence 'a' command) - meaning you don't have to pay attention to the cursor position, it could be on the start/middle/end of the word and the result would be the same.

[capote]

Ah. Now I look like I'm vim-dumb.

[soyiuz]

No worries. There's always more to learn. `dw` is a motion command as in "delete to the end of the word. `daw` is a text object command as in "delete a word." There is also a difference between `daw` and `diw`, which is delete inner word, and `daW` which is delete a WORD.

See http://vimdoc.sourceforge.net/htmldoc/motion.html#object-mot...

and

http://vimdoc.sourceforge.net/htmldoc/motion.html#word

[hurbledr]

I'd imagine it's because delete a word is easier to remember. Just sticks in the mind better, if that makes sense.

[meric]

`daw` will delete a word

The equivalent in any Mac OS X text editor is:

alt-left-shift-right-backspace.

[soyiuz]

It is not quite the same, as per above comment. `daw` will delete the word regardless of the cursor position. Vim has the idea of text objects beyond "end of the word."

[towb]

My main reason to why stuff gets done faster when I'm in vim is because I am in the terminal anyway. Compared to one virtual desktop with a browser if you're doing web, one with some editor, and one with a terminal to run some build tools and more, you'd have to jump around much more.

Another good reason to go with vim is that it will probably be around when other editors may become abandoned. Sure it's good with many editors to pick from, but most of us go for the latest shiny thing and it's always a learning curve even going between Sublime and Atom.

It's free, you can install it on anything. It's not the crazy commands that makes it fast really.

[charleshmorse]

Watch Gary Bernhardt at https://www.destroyallsoftware.com/screencasts and judge for yourself.

[facorreia]

I use vim not because I think I can type faster in it, but because I have used so many editors in so many different platforms over my career, and I realized that I could settle for just one that I can trust will be around (and be very effective, and available on any platform I choose to use) for as long as I'm alive.

[mchahn]

> Can you show me how fast coding is in vim?

I would literally like to see how fast coding in vim is. Can anyone point me to a screen capture of editing in vim? I've always been skeptical how editing without a mouse could be fast.

Edit: I just noticed that he is asking for a screencast. Why is everyone ignoring that request?

[zippy786]

Programming is about typing less, writing small and smart code that is hard to break and requires thinking. I never understood why fast editing in vim matters for good programming. You can pretty much do copy paste, replace or refactor using any other editors.

[japhyr]

Anyone following this thread might be interested in watching a few episodes of Emacs Rocks! It's pretty entertaining, and humbling about my own use of any text editor.

http://emacsrocks.com/

[madcocomo]

The advantage of Vim is not faster but more abstract way to manipulate text. It build a language of text operation in higher level, which make you faster. Image picture editor which has only concept pixel, but not sharp, mask, layer...

[yitchelle]

I don't think it really matters which editor you use. Just pick one, and be proficient with it.

All of the editors you've mentioned are very good at what they do, some might be better in certain areas than others.

[a13n]

I used to use vim for everything and about a year ago switched to using Sublime Text with a vim plugin. I get some nice IDE features with all the power tools that come with vim. Highly recommend.

[manibatra]

Same! Love it

[pklausler]

If you're still using QWERTY, fix that first before worrying about your text editor.

[mod]

I disagree here, as someone who has done both (though admittedly I'm back to qwerty).

Dvorak or similar will result in a typing speed improvement, and some physical benefits, but typespeed is rarely the limiting factor when coding.

[bcheung]

I use Dvorak if I'm typing English and it's a full sentence or more. But trying to use vim with Dvorak bindings just seems crazy to me. You wouldn't be able to use the home row arrow keys if you are in dvorak mode. There was some careful consideration with the hotkeys in vim and they were made under the QWERTY assumption.

[pklausler]

Yes, they were, and that's a real problem with vi(m).

[viiralvx]

What's the point of switching to Dvorak when I can already get 125 WPM using QWERTY? I'll pass, on switching.