Everyone Who Tried to Convince Me to Use Vim Was Wrong

http://yehudakatz.com/2010/07/29/everyone-who-tried-to-convince-me-to-use-vim-was-wrong

by mattyb • 16 years ago

309 208 16 years ago

yehudakatz.com

HNer• 16 years ago

long live nano :P

bartwe• 16 years ago

Or joe or pico

davidw4• 16 years ago

With emacs, you'd still likely be a bit less productive initially, but at least it doesn't have that weird "insert mode" stuff, so you can use the arrow keys, backspace, and so on.

stevejohnson• 16 years ago

Sounds like you miss the point of the article: that you can make vim at least as incremental as emacs if you take the right approach.

davidw4• 16 years ago

I got that, but I think emacs approach makes more sense, even though it's still by no means an easy system to deal with for a novice.

andrewf• 16 years ago

Arrow keys work fine in VIM, whether you're in insert mode or not. The argument for not using them is that it's less productive to use them than HJKL, because you need to move your hand back and forth between the home row and the arrow keys.

I never broke the habit myself, and I suspect the benefit is a lot smaller on a laptop keyboard versus an AT keyboard.

edanm5• 16 years ago

I highly recommend getting used to it. Being able to keep your hands on the home row, even on a laptop, is a huge boon; I can't really claim it's a productivity increase (I have no idea if it is), but it just feels so much better and more fun to type that way.

Actually, the same is true of most vim stuff: does being able to delete text 2 seconds quicker really make you more productive? Beats me. But after you get used to being able to tell the computer what you want to happen and have it happen (e.g., delete everything inside these parentheses), using the old method of moving around the cursor just feels bad.

throw_away• 16 years ago

The far better argument for not using arrows while in insert mode is that it hinders the learning of the difference between insert and normal mode. Once you get used to there being a strong difference between the two, you end up using the more useful motion commands such as f/t or ) or #/*. these motions usually get me to where I want to go faster than hjkl would, not to mention the benefits of being able to compose advanced motions and commands.

When I help people learn vim, one of the first things I do is disable the arrow buttons in insert mode. I tell them that they should avoid using them even in normal mode. I feel that this crutch ends up hurting you in the end. On the other hand, writing text in non-vim contexts is maddening with all it's arrow-arrow-arrow-backspace-backspace-backspace pain. I don't see how 99% of people can stand to do it this way :)

edanm5• 16 years ago

From my experience, each has its own problem. While learning emacs, you're very likely to hit a few keys by accident and suddenly have a new open buffer you don't understand; it takes some time to learn to hit c-g c-g every time something like that happens (is c-g quit? I'm pretty rusty these days).

Vim has other problems (like the insert mode), but even in vim you can do as the author says: always be in insert mode, and pretend it's just a normal editor.

leif3• 16 years ago

C-g is quit. :)

The difference is (full disclosure, I pray at the altar of emacs now, after many years of vi), much of vim's functionality is hidden if you stay in insert mode, while in emacs, you always have everything available to you (and in many cases, it'll suggest "next time, use this shortcut").

lelele6• 16 years ago

Yes, "C-g" is `keyboard-quit'. And if you make some damage by hitting keys on accident, "C-h l" (aka `view-lossage') will show you the last key presses, so you can know what you've typed. "C-h k" (aka `describe-key') will tell you what command a key sequence runs.

EDIT: Added command names.

alinajaf• 16 years ago

Both tools are as good as the amount of effort you put into learning them.

phreeza2• 16 years ago

Can we please not have ye olde flamewar here? Not flagging or accusing you of that being the intention btw, just saying...

davidw4• 16 years ago

Sometimes, what with all the new things these days, I think it's opportune to remind people that emacs (and... ok, I'll admit it) vim are still there and still great tools.

SwellJoe• 16 years ago

I always say in any text editor flame war (usually one with little kids claiming that they're more productive in their fancy-pants new mousey editor that widgets and icons and zoomy things and little colorful spinny wheels while it thinks about deep texty problems):

Editing text is a solved problem. vim or emacs, pick one and get back to work.

JustAGeek• 16 years ago

The title of this blog is quite unfortunate imho, it really is an article describing how NOT to switch to VIM and how the author eventually managed to come up with a good way of switching.

Good (and as so often, kinda obvious ;) advice.

phreeza2• 16 years ago

I agree. Makes me wonder if the OP would have been chastised for retitling, if he had changed the title to be more reflective of the content.

wycats• 16 years ago

I thought a bit about how to title this. On the one hand, I'm talking about successfully switching to vim. On the other hand, the thrust of my argument is that I got very bad advice repeatedly over several years on the topic.

Apologies if the title wasn't as reflective of the content as I had hoped.

kashif• 16 years ago

Totally ineffective. May you enjoy your vim days.

gaiusparx• 16 years ago

Any reason why vim instead of emacs? I use textmate and might give vim/emacs a try again. Quite similar to your old experience.

dtf• 16 years ago

For the eight years I've been using vim, I have never known about ci". I feel both stupid and in awe.

Sukotto• 16 years ago

I suggest you consider two rules from journalism:

Firstly, that your title should align with the broad story "I like Vim now / Vim is pretty good" as well as the specific story "The usual advice on how to switch is wrong". Your title strongly implies that Vim is not worth learning and that you should ignore people who suggest you try it.

Secondly, that you should start with your conclusion and slowly expand on it. This is because you don't know how much of your article any given reader will read before giving up or getting distracted.

These are both a non-trivial effort. How do you, for example, convey the entire meaning of the article in the title while still making people want to click and read? How do you hit them with the key argument of your story without building up the foundation?

SkyMarshal• 16 years ago

Fwiw I liked the title. As someone ramping up on vim, it definitely caught my attention, and was cleverly related to the rest of the article.

confuzatron3• 16 years ago

I just saw it as a witty title, rather than an unfortunate one.

antileet• 16 years ago

After about four years of using Vim, I'm starting to see it's more of a paradigm (and almost a philosophy) built into an editor, rather than the editor itself. One thing many people complain about when they switch to Vim is editor's inability to understand their code unless they set up exuberant ctags, etc. Even then, the code completion (omnicomplete, supertab, etc) isn't to the grade of commercial IDEs.

It's only in the past few months, I've realized that every major IDE out there - from Visual Studio to Netbeans have plugins to enable vi-mode. Heck, many popular ones like QT Creator, KDevelop, MonoDevelop have Vi mode baked in right into the IDE itself, ensuring a high degree of integration. This gives you the best of all worlds - you get an intelligent, yet efficient editor.

A lot of projects exist, like VimWrapper[1], which enable application developers to embed Vim, or to emulate its functionality without excessive efforts and re-implementing the same code again and again. The Netbeans protocol in Vim is still used by editors like Pida to skillfully embed the entire editor, and there are great projects like Eclim, which prove the degree of integration Vim can have with its environment despite the governing policy discouraging interaction with external tools.

Personally, I switched to Emacs for two months (or tried) but found that with some tweaking, most of what can be accomplished by Emacs can be done using GVim. I feel, that with a little effort, the vi-emulation in Emacs itself can make for a better generic editing experience than either of the standard editors.

railsuser• 16 years ago

Has this been the cause of the rails 3 release delay? :)

fragmede• 16 years ago

He didn't mention my favorite method for learning vim: print out a cheat sheet (A PDF is not good enough) and keep it next to your computer.

Jach2• 16 years ago

I didn't get really into vim until I got the mug: http://www.thinkgeek.com/homeoffice/mugs/7bbe/

I remember when I first learned HTML (without CSS). It was simple to get the basics down, I memorized a few basic tags and attributes, and over time I learned more and more tags/attributes until I had a respectable catalog memorized that I could use when needed. It's similar with vim, but I find even after years of using it I can still learn new, neat features about (or packages for) it. (P.S., thanks to the article author for the ciX command.)

city41• 16 years ago

Thanks for that, that mug is great and I just ordered it.

sophacles• 16 years ago

I have found that I can go learn and forget entire ways of using vim for years at a stretch. I've given up on trying to learn all of it, and instead just go into "deep vim mode" every 6 months or so, and (re)learn about a lot of stuff and adjust my vimming for current workflow optimization.

hartror• 16 years ago

I have a dog eared piece of paper that I referred to for learning emacs.

leif3• 16 years ago

For those not running Apple software, http://cream.sourceforge.net/ is a good beginners' "flavor" of vim. It gives you some familiarisms to work with until you find their more powerful counterparts.

troels2• 16 years ago

When I began using emacs, I started out by modding it heavily, so that it didn't act all that emacs-y. Besides being a fun exercise in emacs-lisp, it smoothed the transition quite a bit.

I would certainly suggest anyone switching to vim or emacs that they mod the heck out of them, just to make it bearable. You can always peel the mods off once you get more comfortable with the tool. After all, what makes these editors so awesome in the first place, is exactly that you can mod them.

mahmud• 16 years ago

I was quite the opposite. I got the old sturdy Emacs 19 manual (printed by HP Press) and put that well-bound beast on my desk. I started doing everything with emacs; calendar, IRC, calculations, spreadsheet, notes, debugging, running Perl, running connecting to a remote box, etc.

I am one of those rare people that can't use MS Notepad; I routinely get weird dialogs popup in applications because I use emacs key-chords from muscle memory.

__david__• 16 years ago

Me too. I also tend to zip to the beginning of the line a lot, out of habit. Trying to save in notepad or a windows editor can do really bad things: C-a C-x C-s. Ouch.

angusgr2• 16 years ago

This actually almost the opposite experience to what I thought most people had with emacs.

After all, emacs comes out of the box with menus, a toolbar, normal keybinds, to set people at ease if they are used to "normal" text editors like Notepad or Word or something. At least GUI emacs, that is.

I thought that it's after you learn a bit more about emacs that you normally turn all those things off and just rely on commands and key bindings and your own custom modifications.

An aside: In my experience, it also seems like this "newbie-friendly" environment sometimes turns off vim users who consider emacs to be somehow "less hardcore" and therefore worthy of scorn. Which is weird for a few reasons.

dfranke• 16 years ago

You kind of need the menus. A lot of modes rely on them outright, and even if they don't you still don't want to memorize a new set of keybindings for a mode that you'll only ever use once. The toolbar, though, isn't much besides a waste of screen real estate.

troels2• 16 years ago

Well, I actually disabled the menus and toolbars. I came from using Textpad for about 10 years, so I had some very particular ideas about how my editor should behave. I basically removed a lot of the gui chrome, installed tabbar (puts tabs on top), installed cua (cope+paste and selection works as in Windows) mode and then wrote a mode that makes the cursor move around like it does in Textpad. And a bunch of minor tweaks as well. I have used most of this setup for about 4 years now.

I'm pretty much entirely lost in a vanilla emacs installation.

ecaradec2• 16 years ago

I switched to vim, because I wanted a command from visual studio. That command was "of" that allowed to open any file of the project with incremental completion. I know that many consider VS to be a crappy editor, but if you know many shortcuts, command console and macros it's actually nice.

But it's an IDE and I needed something for javascript files and html files that was in the range. So I switched for this only reason. I switched the exact same way you did, using the mouse at first, I spent time in the help for every issue I had, I learned motions, macros, etc...

Interestingly I've never found something as neat as the "of" command of VS, but I loved all the rest.

dan005• 16 years ago

"That command was "of" that allowed to open any file of the project with incremental completion."

Have a look at http://www.vim.org/scripts/script.php?script_id=1984. I love it!

ecaradec2• 16 years ago

I tried it but I often work with lot of subdirectories and many files and that script abort when it reach 200 files. Increasing the limit beyond that would be slow. I use the Project plugin switch to the buffer, search with incremental completion. At least it's cached so it's faster, that's not to bad, but I find it less integrated than VS.

pyre2• 16 years ago

http://www.vim.org/scripts/script.php?script_id=1890

sliverstorm2• 16 years ago

In reply to the title, I have one thing that should convince certain people to learn vim.

Besides cat, pipes and grep, vim is the only useful editor (i.e. works in the command line over ssh) you can count on always being on every *nix machine. There are a very few it is not included in, but these do not have any other editors either.

pmccool• 16 years ago

> There are a very few it is not included in, but these do not have any other editors either.

I'm curious: when have you come across an editor-less unix?The vi-less ones I've come across have generally had some bizarre substitute that uses wordstar keystrokes or something equally obscure...

You raise a fair point, though: knowledge of vi = knowledge of ed which will work even when vi won't (horrid slow link and/or broken terminal emulation).

sliverstorm2• 16 years ago

most commonly rescue or pre-boot environments. A rescue environment without a text editor is severely hampered, it's true, but sometimes things other than config files need rescuing, and floppies are small.

gvb• 16 years ago

I've come across ones with only "ed", but the last time I had that was 20-odd years ago. I would counter all unix (like) operating systems have an editor because I've never run across one without "ed" (and "sed").

Deadsunrise• 16 years ago

vi yes, but vim is not always installed.

maweaver• 16 years ago

True, but if you have command line ssh access you could also use Emacs' Tramp Mode to transparently edit the files using your local editor.

Schmidt• 16 years ago

Which is true for Vim as well, using the :e scp://host.com/path/to/file :)

chewbranca• 16 years ago

Sad to say that vi/vim has not been installed on every *nix box I have used. Its not installed on freenas by default, which I have running on a box. My mind was blown when I realized it didn't have at least vi.

ralph6• 16 years ago

No, vi often isn't installed, e.g. on Linux ADSL routers. If there is one editor it will be ed(1), the one true editor. :) That's why everyone should know it. Besides, it is a bit easier to use ed blind to edit a file from a mental image of the file's contents than it is vi.

zikzikzik• 16 years ago

"The last few times someone tried to get me to switch to vim, I issued them a simple challenge. Can you tell me a way to switch that will not significantly reduce my productivity for the first few weeks."

The problem with this argument is that it clearly shows why so many people get stuck in local maximums, even though there are much higher peaks around, one just has to walk downhill first and then uphill again.

It takes sweat.

confuzatron3• 16 years ago

And yet, the guy is now happily using vim. Surely there must be an incremental route between 'using vim wrong' and 'using vim right' that doesn't come with a drop in productivity? If not, what's wrong with the app?

nimms3• 16 years ago

Nothing...it's that the app sacrifices new user accessibility for a more powerful editing paradigm. It requires a dedication to productivity from the user that pays off in the long run.

cturner• 16 years ago

Something that I found odd: he seems to grok the transactional thinking.

I've seen plenty of people who only dip their toes in with vi and never get this. You feel the frustration when you watch them try to use it - pressing the 'x' key repeatedly, or navigating around whilst in insert mode.

I never knew about that ci" usage he mentions. Very handy.

silentbicycle12• 16 years ago

You can make the drop in productivity relatively short (maybe part of an afternoon) rather than a week, but it's still going to be there anytime you learn something that's actually different.

If you pick up a new language (say) and are immediately fluent, have you actually learned anything?

telemachos3• 16 years ago

I agree. The challenge is neither simple nor reasonable. Don't get me wrong: he (and anyone else) has every right to want to be productive, but it's odd to think that switching editors should not lead to some drop in productivity. Editors are important to programmers. A baseball player wouldn't expect a different glove or bat to immediately be as productive as a familiar one.

Katz's counter example is that he "didn’t really have to put up with a huge amount of pain when switching to Textmate for the first time. In fact, it was downright pleasant." Note, however, that (based on what he says about his TextMate usage) all he every did with TextMate was type text. He didn't use snippets or commands much. As he says, "When I really thought about it, Textmate wasn’t doing all that much for me. It was a glorified Notepad which had working syntax highlighting and understand where to put the cursor when I hit enter (most of the time)." So TextMate didn't hurt, but it also did help. In my mind Vim is likely to do both: hurt at first (it's a big adjustment), and help a lot later.

(That said, I don't think there's anything wrong with learning Vim more gradually, as he's trying now. But his initial demand of "no significant drop in productivity" isn't as reasonable as he seems to think.)

njharman• 16 years ago

This is by far best way I've seen to learn vim http://www.viemu.com/a_vi_vim_graphical_cheat_sheet_tutorial...

I recommend people making it their desktop background. Being "in your face" helps you remember to learn and explore things like 'ca)' rather than just hitting delete and arrow keys a bunch.

>"Can you tell me a way to switch that will not significantly reduce my productivity for the first few weeks."

Two obvious answers that came to me while reading that sentence: 1) Use it at home/off hours/for side projects/etc until you are proficient enough to do work with it. 2) Use it for 1 task a day, then 2 tasks, etc.

The "Turn everything off" is stupid way to start. [Altough it's one way to reach next level after you are basically proficient] Clue to OA, find better people to get advice from.

> I was able to get here because I used my [blah, blah, blah]

No, because you stuck it out. Like most worthwhile things Vim is not instant gratification.

kingtoe• 16 years ago

Definitely the best. As a student, I had time to learn vim the slow, hard, purist way, and I struggled for weeks simply practicing, drilling, and tutorial-ing.

Then I picked up these cheat-sheet tutorials and WOW! Just code as usual, but in vi with the first easy cheat-sheet lying in front of you; almost no productivity hit, and you seamlessly build up the cheat-sheet 'till you know all the commands!

The only way to learn vim, I think.

username3• 16 years ago

I tried learning by using cheat sheets, but they don't stick because I don't go back to them for reference or if I do, I forget because I think I'll have a reference later.

Commands stuck when I saw someone else use vim, do something I didn't know about like yyp, and I asked how they did it. I'd like a video of someone using vim for real work and then explaining how they did it.

telemachos3• 16 years ago

Vimcasts provides excellent, free little screencasts about Vim. (http://vimcasts.org/episodes/archive)

PeepCode also sells two screencasts about Vim that I think are quite good. (http://peepcode.com/products/smash-into-vim-i and http://peepcode.com/products/smash-into-vim-ii) Depending on how long you've been using Vim, you may find them a bit basic (especially the first), but Vim has so many nooks and crannies that you will likely pick up some things anyhow.

Symmetry2• 16 years ago

When I started learning vim I put that up on the wall next to me. It was a big big help.

kilowatt2• 16 years ago

Sometimes just knowing something is possible is enough to encourage you to find out how it's done. Probably nothing beats sitting next to a vim pro and watching them slice and dice code.

I didn't have that opportunity, but a few screen casts really opened my eyes as to how far down the rabbit hole I should consider going...this one in particular is a pretty amazing example of someone with some serious keyboard AND customization chops:

http://vimeo.com/7642937

johngunderman5• 16 years ago

What is that refactoring tool he uses to pull code out into a separate method?

jwecker• 16 years ago

I would also recommend quickly getting in the habit of using ctrl-[ instead of reaching clear over (on most keyboards) for the escape key.

silentbicycle12• 16 years ago

Or you can remap caps-lock to escape. I know that doesn't match the whole 'vi is already everywhere (on Unix)' aspect, but it's an option.

jamesgeck0• 16 years ago

When I tried it, I used jj as a shortcut for escape. It seemed to work well enough.

dan005• 16 years ago

I never used it, but perhaps it's a nice way to learn vim: http://cream.sourceforge.net/

setconndevp• 16 years ago

For my MAC i use MacVIM/ Komodo Edit.

barfoomoo3• 16 years ago

A question for the Vim experts. How do I do the below in Vim? I yank a text and then visually select another text and copy the yanked text over the selected text. Once I do this, if I try to visually select another text and copy the previously yanked text over it, it does not work. How does one do this with Vim?

rlpb• 16 years ago

If I understand your problem correctly, you want to use registers. Say you yank a text visually by using V, the arrow keys, and then y. Instead, use V, the arrow keys, then "ay

That stores the yanked text into the "a" register. When you put, instead of just p, use "ap

That puts from the "a" register, and you can repeat the action since the register is never overwritten unless you tell it to. You can also use b through to z to store other things. The same registers can also be used to store macros and marks.

Usually you use the default register (I think it's ") and this register also gets various stuff saved to it automatically (eg. stuff you delete). (This is how stuff like xp to swap the current and next character works)

barfoomoo3• 16 years ago

Thanks for that suggestion. Any idea why Vim behaves like this? Say I visually select something and yank it and then go on pressing p it pastes the yanked text any no of times. But, if I select a text and then try to replace it with the yanked text, I can do it only once. The next time, the yanked text seems to be removed from the register. Why this difference in behavior?

pyre2• 16 years ago

  > That puts from the "a" register, and you can repeat
  > the action since the register is never overwritten
  > unless you tell it to. You can also use b through
  > to z to store other things.

The '+' register is used to interface with the X11 (or Windows) clipboard. Example:

  "+P   Paste from clipboard
  "+y   Yank to clipboard
  "+gP  Paste from clipboard, move cursor to end of pasted text

graywh• 16 years ago

Use "0 before put/paste in visual mode to specify register 0, which always contains the last yank.

drivebyacct2• 16 years ago

I don't understand. It's not hard at all to learn the basics - navigation, visual mode copy/paste, enabling line numbers, turning on a color scheme in 15 minutes. If that.

obneq2• 16 years ago

the only fun way to learn vim is to ascend a character in nethack. once you played for a while you'll know your way around vi!

but vi keys force you to have your right hand in the wrong position. sure its more convenient than bpnf (emacs style memnonics) but i dont like it for typing, especially when using a lot of special characters, that is, coding...

DennisP2• 16 years ago

It's the standard position I learned in touch typing class (jkl;). You're right, special characters are a pain. How do you do it?

obneq2• 16 years ago

vi keys are on hjkl standard position is jkl;.

chwolfe• 16 years ago

I highly recommend A Byte Of Vim for anyone wanting to learn the editor: http://www.swaroopch.com/notes/Vim

crux2• 16 years ago

I think the key distinction that Katz is failing to make is this: switching to Vim is not a matter of 'You’re learning a new EDITOR for God’s sakes. Of COURSE there’s going to be a learning curve.'

As pointed out, Textmate is a new editor and you don't come to a standstill when you use it for the first time. But Vim is a fundamentally different KIND of editor than Textmate. It's not that it's a different program. It's that it's probably the first modal editor you've ever used. As far as I'm concerned, the whole bulk of the first and hardest step in learning Vim is just wrapping your head around editing modally. Whether you want to disable your arrow keys and obsessively leave Insert mode, in order to cultivate good habits, or you just want to muddle through and implement Vimisms where you can is wholly up to the reader. It's analogous to whether you want to cover your keycaps and use dvorak all the time even when you can't touch type, or just ease into it. But the hump, the bit that's a qualitatively different experience, is the modality of the application.

techiferous• 16 years ago

Speaking of dvorak, I use dvorak and that's one reason I haven't entertained the idea of switching to vim. If I understand correctly, vim assumes qwerty.

crux2• 16 years ago

You can easily download alternate keymaps that adapt it to dvorak. Vim assumes qwerty, and thus things like the movement keys are remapped; but it doesn't really matter where the majority of the keys are. Most of vim's key layout is semantic rather than positional.

bmallerd• 16 years ago

This is a common misconception. There are SOME niceties in VIM that make more sense in qwerty (i.e hjkl for up, down, left, right respectively) but most shortcuts are NOT keyboard layout dependent. VIM's shortcuts are mostly mneumonics. For example, if you wanted to "delete a word", you would enter dw. In my head I think dw, not home-row+middle+left-hand, ring-finger+left-hand+top-row. Don't let this qwerty/dvorak be an excuse. Just do it. ;)

silentbicycle12• 16 years ago

I've used Dvorak for years, and have no problem whatsoever using vi and Emacs with it. (I use Emacs for major work and nvi for quick edits in the shell.) Emacs is significantly better with Dvorak, IMHO, because there isn't so much mashed together on the left hand.

The only thing I've ever had a hard time getting used to with Dvorak is the diagonal movement commands in nethack. hjkl is not a big deal, but yubn trips me up.

tokipin• 16 years ago

other than me using 'ce' instead of 'cw', it isn't any different. this stuff is very muscle memory-ish. the location of the keys is not really a factor except for finger collisions such as 'cw'... which is the only such collision i remember noticing

hjkl is kind of a red herring in this case. those keys happen to be bunched together in qwerty, but that's an irrelevant accident of history, and those keys are not used very commonly to begin with. at least, they shouldn't be used very commonly. much better and faster keys are: 'w', 'b', 'I', 'A', '{', '}', 't', '/' etc.

rue• 16 years ago

    " Dvorak
    " Normally, < ^ v > == h k j l
    " Here,     < ^ v > == h t n s, d remains delete 
    noremap t k
    noremap k t

    noremap n j
    noremap j n

    noremap s l
    noremap l s

(And for those accustomed to vim, there is no error in the layout.)

william42• 16 years ago

I switched away from vim when I switched from qwerty to dvorak because I didn't want to relearn all the commands.

hyperbovine• 16 years ago

I switched to both Vim and Dvorak cold turkey at the beginning of this year. (I figured as long as I can't type, might as well be unable to edit things too.) I am not sure if not having prior knowledge of QWERTY Vim makes any difference, but I have seen no downside to using Dvorak. The most common complaint I see--the hjkl thing--isn't even an clear-cut disadvantage. Now they are on two different hands and I think it makes movement faster. Vim commands are all mnemonic, so unless you Vim has penetrated so deep into the subcortex that it's all muscle memory, learning shouldn't be much of a problem.

Definitely gratifying to hear this guy's experience, BTW. I got religion when it comes to Vim. If you spend 8-10 hours a day editing text, it makes sense to put some thought into how you are doing it. Small efficiency gains add up.

andrewvc2• 16 years ago

I use dvorak and Vim. You can remap the keys easily enough, here's my vimrc for example:

http://github.com/andrewvc/vim-settings/blob/master/vimrc

I only remapped some of the keys though. Remapping ':' is really useful, I have it mapped to - (which is , in qwerty), which means its only a step away from my right pinky, no shift required.

MaysonL• 16 years ago

I used modal editors for a couple of decades['72-late 80s], and still haven't managed to become proficient with either vi or emacs (or variants or descendants thereof). Currently just use TextMate or PLT or CCL editors.

WilliamLP• 16 years ago

For me, having tried to use Vim in the past, the pain point is never the editing itself. It's the fact that I need visual step-through debugging, adding breakpoints and watch points, and intuitive navigation through a large file hierarchy including lots of imported files, HTML templates, config files, performing ad hoc database investigation queries, uploading files to a server, and whatever else, along with ability to jump to classes and function definitions and intelligent auto-complete and popping up parameters and catching my variable name typos and so forth.

There's a fundamental disconnect between me and the programmers who say "the only real choices are Vim and Emacs", and I'm fully willing to consider that I'm doing it all wrong, but I wonder if there's anything out there that could convince me that living on the home row in a modal editor can work me through the entire job of being a programmer and maintainer, as opposed to editing and entering text in a single or very few files.

kilowatt2• 16 years ago

With customization, every pain point of yours can be addressed; but maybe that's the problem that makes people "fall back" on IDEs.

andrewvc2• 16 years ago

It probably depends on your stack. TFA's author is a Rails developer, like myself. I've used Rad Rails, the eclipse based Rails IDE, and I just find myself less productive in it than vim + a handful of terminals.

I really tried to like Rad Rails, but I it just felt like overkill, and the interface was too complicated. Besides adding a breakpoint to a rails app is as simple as adding the line 'debugger' to it. No big deal.

I've heard that for Java the situation is reversed, but I'm not a Java programmer so I couldn't say if there's anything to that.

zephyrfalcon2• 16 years ago

"It's the fact that I need visual step-through debugging, adding breakpoints and watch points, and intuitive navigation through a large file hierarchy including lots of imported files, HTML templates, config files, performing ad hoc database investigation queries, uploading files to a server, and whatever else, along with ability to jump to classes and function definitions and intelligent auto-complete and popping up parameters and catching my variable name typos and so forth."

I know what you mean, but... Vim is first and foremost a text editor, and one could argue that none of this is a text editor's job. (In the spirit of the Unix tradition, do one thing and do it well, etc.)

You can customize Vim a great deal, but it isn't really meant to do all of the above. I can see why you would choose to go with an IDE instead.

lee2• 16 years ago

Hey, don't throw in Emacs in there!

I use Emacs for a lot of Python and Django work. I can visually step through debugging, add break points, watch points, and etc... with Emacs.

Emacs was designed with extensibility from the ground up, and there are a lot of debugging plugins that turn emacs into an "IDE".

parfe2• 16 years ago

Can I ask what your setup is to setup break points and step through?

jlongster• 16 years ago

The thing is, you can achieve that functionality whether or not you use Vim/Emacs. The difference is that it won't be so visual, but it turns out that visual clutter gets in the way anyway. So yes, it's harder to get up and running, but it's really efficient once you've settled into an IDE-like environment in Vim/Emacs.

Also, because you've put the glue in place yourself (by hooking up GDB, creating separate windows, running SQL commands as subprocesses, etc.) you've really tailored your environment to your needs. And trust me, once you get to that point, no other IDE will compare.

nuclear_eclipse• 16 years ago

The best part about Vim is that I can take Vim with me when I use both Eclipse and Visual Studio; there are great projects available for implementing the true, modal Vi editing model for both IDEs.

ViEmu, although not free, is a first class Vi mode for Visual Studio, so good that there's barely anything I use in Vim that isn't available in ViEmu.

For Eclipse, Vrapper is an excellent newcomer that implements a pretty large portion of the Vi command set. It's not as complete as some of the other Vi modes for Eclipse, but it's definitely the best integration I've found, and hasn't fallen done in edge cases like the others have.

sreque• 16 years ago

I like getting the best of both worlds. Most IDEs have a vi plugin of varying quality. Netbean's vi plugin has worked excellently for me in the past (http://jvi.sourceforge.net/). I've heard Intellij's is also pretty good. I've found the Eclipse one to be very buggy but still worth using (http://www.viplugin.com/). I've never spent time in the Microsoft developer world but have heard that historically there has even been a commercial plugin available for Visual Studio.

spacemanaki• 16 years ago

Missing from the other suggestions for IDE like behavior in Vim is Eclim, a plugin to Eclipse and set of Vim scripts which hook up Eclipse as a backed to Vim. I just started using it for Android development. You get intellisense,validation, import fixing etc.... all in Vim. might not do it for you but perhaps someone else will find it useful, I certainly did.

milesf• 16 years ago

I think the biggest motivator to learn Vim is to watch people who know how to use it. It's a painful editor to learn, and coming up with the right approach to learn it is not the same for everyone. I equate it to the pain I felt switching from Qwerty to Dvorak, which took me well over a year before I was back up to 50-60 WPM. Now that I'm here, it was worth the switch, but I sympathize with others trying to make the jump. I see the same sort of pain learning Vim.

One thing is for certain: Vim will never die. It's over 35 years old now, almost as old a Unix and C.

lelele6• 16 years ago

Must read: http://derekslager.com/blog/posts/2006/12/the-case-for-emacs...

Jump to the paragraph "The Dark Side".

kevincolyar• 16 years ago

If you're a Vim user on a Mac, check out ViKing http://vikingapp.com

steve19• 16 years ago

Your account was created 12 hours ago and this is the only comment you have posted so I am assuming it is your application.

I was excited when I saw you application hoping it added a normal mode to cocoa text fields but alas it does not.

I know I going to sound harsh and critical, but I really do want you to succeed ... you have a beautiful website but app does not do very much. The shortcuts are not standard vi(m) shortcuts.

Looks to ViEmu for inspiration: http://www.viemu.com

I would love to buy something like ViEmu for cocoa and for Microsoft Word for Mac.

agentultra• 16 years ago

Just go through the included tutorial. That's what got me started years ago.

Though I've switched over to emacs now. ;)

masterponomo• 16 years ago

They were right about what worked for them, but wrong to think it would work for you. While I wasn't there and can't refute your claim of their disdain for anything but full immersion in CLI vi with no GUI aids or non-standard helper keys, it is true that if you want to be able to do basic functions on any version of vi on any system (including one with no graphical environment) then you are better off knowing the keyboard commands. That said, it sounds like you found a way into it that suits your needs...good.

lg• 16 years ago

for similar reasons it's nicer to start with a bells-and-whistles emacs variant like aquamacs, and ease your way into (menu-bar-mode -1) etc.

code_duck3• 16 years ago

Why would it NOT reduce your productivity while you are learning it?

I bet you he'd be happy to say 'OH YEAH SWITCH TO A MAC', but guess what - it will reduce your productivity while you're getting used to new programs, new keyboard shortcuts, etc.

binaryfinery8• 16 years ago

Not really. But then I'm using eclipse, intellij, bash, gmail etc. Its like linux, but I can sync my iphone :-)

code_duck3• 16 years ago

I just bought my first Mac after using Linux for 6 years, so I am speaking from recent experience here. Definitely like Linux, definitely awesome... but it does take some getting used to.

johngunderman5• 16 years ago

lack of a good package manager is holding it back. sure, there is port, but port's library is tiny compared to its linux counterparts...

richcollins• 16 years ago

Your editor is one of the least important differentiators in productivity. The best developer that I know, who is probably 10x faster than me, uses TextEdit and the mouse.

His secret weapon is the ability to quickly and decisively design software. I waste time tweaking and iterating to (hopefully) find a similar solution.

vollmond• 16 years ago

For any other Eclipse users in here (I see it mentioned once or twice in the comments), check out viPlugin. Works in vanilla Eclipse as well as Flex Builder, and presumably any other Eclipse-based IDE. Not sure how I would live without it at this point.

binaryfinery8• 16 years ago

I know people who use vim, and are hardcore. Yet anything my hardcore friends can do on vim, I can do in IntelliJ or Resharper. However there are things I use regularly in these tools that vim cannot do.

These questions are asked honestly and sincerely and I'm genuinely interested in reading responses:

At the end of the day, what is the big deal about a modal editor? How does not-having-to-press-ctrl (or alt, meta, cmd, whatever) for the first key give a programmer any advantage? Is it just the number of these commands that are available - and if so, has someone done a count of commands available in products like IntelliJ and Slick-Edit vs vim? What about the stuff that seems to be missing, like contextual refactoring - or are there plugins / scripts for that?

Without any such evidence, it does seem to me that programmers want to use vim because of a reputation that hardcore hackers use it, not because it actually improves productivity.

silentbicycle12• 16 years ago

Contextual refactoring isn't present in vi because vi was meant to be used in conjunction with the Unix shell, pipes, and so on. It's not a full environment unto itself the way Emacs is. Search, refactoring, and the like would be handled by shell scripts, awk, perl, parsers made with lex & yacc, etc. Unix itself IS an integrated development environment!

There are lots of plugins for vim, but I'm not up on what would be specifically relevant because I do major editing in Emacs. (Also, I think when most developers need that kind of tool support to use a language it speaks volumes about it, but that's me.)

I like Emacs's extensibility and multi-buffer design, but prefer vi's modal keyboard interface. I like its brevity and orthogonality. Number of commands is less important when each combines cleanly with the others. I would love to see a synthesis of the strong parts of vi and Emacs, though I don't expect it to ever happen - Emacs's giant bundle of elisp has way too much inertia for a full rewrite.

How useful are IntelliJ and Resharper for (say) Erlang, by the way? While I haven't used either, those editors look like they're more tightly focused on Java and C#, whereas vi is for editing any kind of text, and Emacs has had at least passible support for every language I've ever used (except Joy). Comparing vi to an editor specifically designed for Java is a bit misleading.

binaryfinery8• 16 years ago

Refactoring could be handled by perl, awk, in theory. Or you could, in theory, right a parser to do it. But I don't know of anyone who has. A simple search and replace, on a big code base simply isn't going to work. You want to add a parameter to a method on class Foo, when 20 other classes have that same method name? What about when Foo is an interface, and you have to do it for the 10 classes with that method name that implement Foo, but not the 50 that dont?

  m.foo( bar baz);

Does this foo need to be changed? You can't know without knowing what type 'm' is. Good luck writing an awk script for that. This isn't a debate about whether or not it could be done. Its about whether or not you can do it faster than I type Ctrl-F6.

If such a tool exists that I can run from bash, please let me know. Otherwise you guys have advanced from type-writer to the early dedicated word-processors that existed in the 80s, but no further.

Jetbrains have refactoring tools for C#, Java, Javascript, Python, Ruby, PHP, Adobe Flex, as well as "basic" language support for most others (but no Erlang I'm afraid).

As you say, vi is about editing text. But the author is a member of the Ruby on Rails core team and a core contributor to Ruby projects, and I put it to you that most people using vim dont use it to edit just text: they edit text that happens to be a language with a formal grammar, and structure both with the file, and outside it: i.e. contextual. Hence, a good IDE will always be better than vim.

I also dispute the idea that, given a new language, vim will be better at editing it. My IDE will likely be able to do exactly the same things vim can do, using the keyboard only, and with (on average) the same number of clicks. However, the IDE will most likely be intuitive, obvious, and easy to learn (e.g. by giving visual feedback), meaning that in reality, even though vim could do as much as my IDE for an expert user, for the average user it wont and never will.

grogers• 16 years ago

One of the best things about vim for me is (for example) the command cib. This deletes everything from your cursor forward to the first "(", and everything after to the first ")", then places you in insert mode. How do you do that in your editor? I'm guessing you use your mouse to select all this stuff and hit backspace, which is a bunch slower.

Moreover, the command cib itself is built from composeable parts - c (not sure what the mnemonic for this is but its delete then enter insert mode), i (inner), b (block of parens). There are several commands besides c - d (delete), < (left indent), = (auto indent), etc. And these compose with any motion, eg gg (goto line 1), G (goto end), w (next word), etc.

So you have all these powerful ways to jump around the file, and you can combine them with all these powerful ways to manipulate the file. And this is just one of the really nice things about vim. The "." (repeat last command) is something I haven't found in any other text editor, and was the main reason I got hooked on vim.

binaryfinery8• 16 years ago

Ctrl-W is "select word" but it expands each time you press it. So if I'm in the middle of a string, and that string is part of a method call:

( "some string" )

And I press Ctrl-W, then at first "some" will be selected, then "some string", then ""some string"" (with the quotes).

So assuming that moving my thumb to Ctrl is free, I did it in the same number of key presses as you. Or its 4 vs 3 if you count the ctrl key. Or its 4 vs 4 if you are in insert mode and have to esc first. [Edit: ok, you have to press delete too, so its 5 vs 3 or 5 vs 4.]

The difference, however, is that Ctrl-W is all you have to know. Its just as fast as all your different combinations even for the worst case, but:

a) its often faster - i.e. just two Ctrl-W's for selecting the text inside the string.

b) it provides visual feedback.

Its just as fast for the expert, but yet its obvious, intuitive, and lends itself to discovery based learning. Once you know Ctrl-W selects a word, there's a good chance a user will learn its advanced features by accident, even if they aren't told.

Goto line: Ctrl-G 10.

Goto first line: Ctrl-Home (standard in most GUI editors)

Goto last line: Ctrl-End (also)

The '=' auto indent feature: Ctrl-Alt-L Enter is "format entire file". Its fast, so why would you ever want to format just a little bit? Ctrl-Alt-L Alt-A Enter is format the entire project. I dont have a binding for indent, because why would I ever want to? Just write code, then let editor make it look pretty in one go with Ctrl-Alt-L Enter.

I assume the "." command is used to say repeat a replace or a find: in which case there are keys for that. I'd like to see some use cases for that other than find and replace.

Editors like IntelliJ, SlickEdit, Resharper, all have powerful keybinding support. SlickEdit has a built in scripting language if you want to go crazy. All have far more commands than are actually bound. SlickEdit has a vi mode even.

So you haven't convinced me that vim offers any advantage over a good IDE.

silentbicycle12• 16 years ago

c is probably "change". (Or "convert, I guess.)

You can also preface those with a quantity. As a pretty arbitrary example, 5dwelp* is "5 delete-word move-to-end-of-next-word right paste", or, "move the next five words forward one word".

In Emacs, repeat is C-x z, by the way, and then you can just keep hitting z.

ralph6• 16 years ago

c is for change, as d is for delete, i for insert, and s for substitute.

kgo• 16 years ago

Some more advice for someone trying to learn vim or emacs...

RTFM! ;-)

O'Reilly has good intro books on both of them that you can work through in a weekend.

Yes, I know it seems silly to have to read a book to use a text editor, but working through the book and doing the exercises the same way you would for a programming language or API makes the learning curve much, much easier.

fretlessjazz• 16 years ago

Everyone who tried to convince me that (vim|emacs) is better than (vim|emacs) was wrong

anthonyb• 16 years ago

This should be standard practice when you're switching to any new thing (editor, codebase, application, etc.) and is the reason why we have things like continuous integration and Joel Spolsky ranting about starting over from scratch. Going completely cold turkey on the old and diving straight into the new is a really tough way to go.

bfung• 16 years ago

taken from RMS answers 25 questions from reddit (http://news.ycombinator.com/item?id=1559075):

  25. meeiw: What is vim doing better than emacs?

  -----------------------------------------------------------------------
  RMS: Sorry, I have never tried using vim.
  I never felt I deserved such a large penitence ;-).

So OP, you're not alone. =P

Can we move emacs vs. vi to somewhere not HN, pretty please?

Everyone Who Tried to Convince Me to Use Vim Was Wrong

Related Stories