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.
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.
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.
I've never understood this. I have to take my (other) hand off to hit esc and get out of insert mode anyway. Additionally the fact that vim (as opposed to vi) gets rid of the diagonal movements negates a lot of the benefit for me. I also switch into "nethack" mode when I try to use hjkl and that's never good for productivity.
First, you can use ctrl+[ to get out of insert, which means moving your hands less.
Even better (but requires customization), you can remap "jk" to get out of insert mode. Since "jk" is a combination that never comes up in actual writing, it works great. And it means you don't have to move your hands at all from home row.
To help the parent and or vim newbies avoid a google, and to show why this "customization" isn't scary or hard, all you need to do:
:imap jk <Esc>
(Literally type the angle brackets.) And if you want this as a standard default, make a .vimrc file in your home folder and stick the above without the colon in there.
In English, maybe. In Danish there are plenty of jk's in actual writing. Ctrl+[ is terribly inaccessible on a bunch of international keyboards. Ctrl-C is the good one, really.
The point is to map some easily-typed, but rarely-used, key combination as your escape key. I use jj. On the rare occasions I have to actually type jj, I just wait about a half second after typing the first j, and then the second j is received as a separate keystroke, and not interpreted as the second part of a mapping.
And the only times I remember having to actually type jj are when I'm having the Vim keymapping conversation with somebody who asks "So how do you type 'jj'?
It's a shame that all tutorials apparently tells you to use ESC to get out of insert mode. The real way to do it is Ctrl-c, which keeps you on the home row. It works even better if you map Caps Lock to Ctrl.
Ctrl-O takes you to normal mode for a single command and then automatically goes back to insert mode.
Frankly, I find it easier to map Caps to Escape.
Only problem is when you use other people's systems and you keep hitting caps lock when you mean to hit escape (Even if you're not in Vim)
The trick with mapping Caps Lock to Ctrl is that you can use it for all your regular Ctrl-shortcuts. At least on MacBooks the regular Ctrl is placed totally impossible.
But yeah, I /can't/ use others computers without getting utterly frustrated because of that. :)
If you have a proper keyboard with a wrist rest, you only have to extend your fingers to press esc (not actually lift your hand, or move your whole hand which requires moving your whole under arm, if you're typing on a keyboard without wrist rest and where you have your hands hover over the keyboard. Ctrl-c requires you to twist your wrist in an awkward angle, several times a minute. If you keyboard really puts the esc key far away from the home row, you can remap caps lock to esc.
All of this assume that you type 10-finger blind, but I guess if you can't even do that you have other priorities than learning vim.
Taking your hands off of home row to get out of insert is also easily soluble -- you can map literally any key combo to esc. I use command-i (on a Mac), which is effortless to type and feels nicely symmetric to using i for insert.
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 :)
This is by far the best vi/vim introduction I've ever read. Not because it makes you instantly proficient with the editor -- there are other tutorials for that -- but because it does an excellent job explaining how to use it properly.
In Vim, especially the GUI version, it's perfectly possible to just press 'i' and then putter around in your text file, moving around with cursor keys and Home/End and such, deleting, typing, and only occasionally dropping back into "command mode" (as it is often called) to delete a line, or search for something, or save the document (assuming the GUI version doesn't have key bindings set up for this already). I used Vim like this for over a decade, never really understanding the point.
As the article points out, this is completely wrong. You stay in command mode (called "normal mode" here, which gives it a different feel immediately -- it's the mode you normally should be in), and switch to insert mode only to type short bursts of text. Everything else is done in command mode.
While this seems weird at first, once you start getting the hang of it, it starts paying off big time. There are a zillion commands that do something and then enter insert mode. I used to think they were completely redundant; there's already 'i' and 'a' to do that, why have more? Because, obviously, when you spend most of your time in "normal mode", this allows you to execute a command and immediately start typing text. E.g. to insert a new line below the current one, you press 'o', and Vim inserts the line, indents it properly (if you have autoindent set), and is ready for typing.
While this is hardly heavy wizardry, once you know a couple dozen of these commands, editing becomes a very different experience. You just move through the text differently.
Anyway, the article explains this, and a lot more, much better than I can do it here. :-)
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.
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").
OTOH, I pray at the altar of Vim while being into the church of Emacs ;-)
Modal editing is unbeatable. GNU Emacs + Viper + Vimpulse is the way to go.
I agree that Emacs allowing you to access commands while inserting text is nice. However, what are you doing in Insert mode? Hit Esc as soon as possible, my friend ;-)
You wrote "stay in Insert mode", therefore I thought you were making the mistake of staying in Insert mode longer than needed (if I misunderstood what you meant, please ignore my rhetorical question).
I didn't become proficient at modal editing until I followed the advice of staying in Insert mode as little as possible, just to enter short bursts of text (and then remapping the Esc key becomes a must).
I was saying something about the post I replied to, I wanted to point out that it's easier to ease into emacs without sacrificing the chance to learn about it for familiarity.
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.
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.
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.
"I used to believe that for a long time, but recently I have been far more productive in an ide than in Emacs."
Believe me, then the programming language is the issue, not the editor.
It's especially funny, if people claim that their ide is superior, because they can automatically generate boilerplate code, but never question their programming language.
It doesn't seem to matter what language it is - the problem is that I can't remember all the valid function/class/type names and what kind of arguments they take.
Autogeneration of code is nice when I write Java code, but even Haskell has a bunch of boiler plate import codes, as does Python and Ruby.
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.
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.
as a textmate to vim to emacs user, I'd say that vim is to textmate as emacs is to vim. Vim is awesome, but it's still just an editor. Emacs is an operating system that's built around editing text. You start with a powerful editing paradigm and then apply it to pretty much anything you need to do as a programmer...it's about the best editing experience I've ever had. My shell, source control, organiser, messaging, documentation, directory browsing, irc, document viewing etc is all done from within my text editor with all the awesome editing capability that 23 versions brings with it...also you can run vim from within emacs...
Exactly. Emacs didn't start on Unix IIRC and seems to prefer to have everything built in. vi was created by Bill Joy on Unix and wanted to work with the rich language of shell commands from the start, as ed(1) did, so it concentrated on editing text well and integrating with Unix well. To see some Emacs users you wonder why they're even bothering to run on Unix. ;-)
Emacs is a better IDE than vim, but vim is a better editor than emacs.
Emacs is far easier to script and plays nicer with other programs so there are more, more useful extensions for working in various languages. On the other hand, I find vim's modal interface faster and easier on my hands than emac's chording interface. viper-mode in emacs might be ideal.
Ergonomics. There's an emacs key chord for everything, but many of them involve two or three modifier keys.
i.e. search and replace is Alt+Shift+5, indent block is Ctrl+Alt+\
These require some finger contortions. I haven't used vim, but the impression I get is that similar commands in vim are all closer to home row so you don't have to contort your hands as much.
I use emacs for most of my text editing. I hate using vim because I find all the mode switching to be really annoying. I like how keys always mean one thing in emacs, even if it results in the occasional bit of emacs pinky.
'i' and 'a' (mnemonic: the 'a' grabs all of something (and its white space) as opposed to 'i' which grabs the inner part) as modifiers for 'c', 'd', 'y', and 'v' can be very useful, but I don't see them talked about much in most tutorials.
See :help motion.txt - they're in section 6. Text Object Selection. Also, just play around with them a little. For example:
<p>This is a tes|t. Do not be alarmed.</p>
If that's your text, and the cursor is at the pipe:
ciw # remove all of 'test', enter insert mode
caw # remove the word 'test' and preceding space, enter insert mode
vit # visually select all the text within the <p> tags
vat # visually select the whole <p> element
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?
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.
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.)
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.
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.
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.
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.
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.
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.
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.
But once you get past sqrt(15i*π)/2 emacs mastery, you stop using the menus and start using M-x with tab completion. There's a standard naming scheme, and usually local commands are prefixed with the mode name. And in any case, there are generally far more than fit on the menu anyway.
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.
I'm pretty much entirely lost in a vanilla emacs installation.
This is actually one of the things which stops me from going too crazy with my emacs customizations. I have a lot (and long ago disabled toolbars, menus, etc.) but occasionally using coworkers' emacs, and using 'zile' on my OpenWRT routers and the like, means that I like to be able to remember the emacs defaults for most of the common things. :)
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.
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.
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.
> 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).
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.
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").
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.
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.
"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.
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?
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.
I am getting conflicting messages - Yehuda Katz seems to be having a lot of success with the incremental method. I like the phrase 'dedication to productivity' though - sounds dead noble, like how a Samurai might use a text editor.
I think part of the reason that vim and emacs are so powerful but also so hard to learn is that they were created before we had nice homogenous operating environments with a standard 108 key keyboard and Graphical User Interfaces.
They both come from a day when all UI's were text based and so it's not surprising that they offer more powerful editing models than newer alternatives, considering they've both had 30 odd years of refinement.
It's also understandable that people find them more difficult to use. The major advantage that a GUI has over a text interface is that it's more discoverable and given that most people these days have grown up around GUI's, we thus find text based UI's intimidating.
Either way, as developers, most of our day to day tasks revolve around editing text, so I'd say that using a tool that's aimed at giving us maximum textual love is a good thing.
The main issue is that any text editor which is sufficiently advanced will be far removed from the standard CUA + GUI model that most people are used to. With such a separation, everybody has to start at ground zero when learning the new editor. CUA modes are the only sort of learning-curve helper that I can think of, but that doesn't help much because then people just keep their dependence to CUA. They have to immerse themselves in the editor to actually learn it; not get caught up in a "compatibility" mode that makes it easier to use when they start.
But why must powerful editors be far removed from CUA? As I see it, the only reason emacs/vim aren't CUA is that they were written before CUA existed. Couldn't an editor be made, with the same power as emacs/vim, but that did take advantage of all the modern things we've been accustomed to?
And don't get me started on asking why, after all this time, emacs still defaults to non-CUA when it has a perfectly good mode that emulates it? That's just asking to keep new users away.
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.
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?
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.)
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.
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!
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.
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:
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?
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)
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?
When you select some text and 'put' over it, Vim yanks the selected text into the default register. The text that you just put is still put-able via "2p, if you'd like to put it again. Vim is essentially saving that selected text for you, just in case.
> 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
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.
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...
You poor sod, you haven't been shifting your entire hand to be over hjkl, have you? Just maintain standard homerow position and hit 'h' the way they taught you in school.
But you are not meant to put your index on "h". "jk" are the most used keys, therefore your index should rest on "j", like touch typing wants you to do.
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.
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.
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.
incorrect. insert mode is still 'i'. and search is still '/'. They are at different places on the keyboard but nothing changes except for the one single thing: hjkl that could be used to move the cursor are not as neatly together now. You can talk to a qwerty vim user w/o any problem. just don't tell him to press the "third key from the left" or smth ;).
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. ;)
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.
Yes. By and large, it only preserves the aspects of Emacs I don't care for. (It is in OpenBSD's default install, though. That's cool.)
I like Emacs's extension model, and its "everything is a buffer" design, but dislike its modifier-heavy keybindings. I like vi's modal interface and general command orthogonality, but would rather have a persistent, extensible, etc. environment. (Also, I like Lisp, but elisp kind of sucks. And I have written, and continue to write, a fair amount of elisp.)
On the balance, Emacs works better for me, though if a synthesis of the two with a good extension language (I nominate Lua) ever comes along, and retroactively gets the ten programmer-centuries of work it'd take to match what Emacs has, I'd switch in a heartbeat.
Also: Yes, I know about Viper and the other vi-emulation modes, but people who write Emacs extensions follow the cultural standards for keybindings, etc. Including me.
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.
HJKL's location on a QWERTY keyboard directly influenced them being chosen. They were to hand under the right hand, and mnemonically, ^H is BS, ^J is LF, ^K is VT (vertical tab) which at least keys the vertical connection going, and L is just at the opposite end to H. :-)
" 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.)
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.
vi commands $, %. and ^ are conveniently placed on QWERTY; Shift-4/5/6. If you use the one true style of braces for your C code then you can move through if-else-if chains quickly. $ moves to the end of the line, placing you on the open brace, % moves to the matching close brace at the start of the next
} else if (...) {
line, repeat... To go the other direction, ^ moves you to the first non-white character, the close brace.
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.
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.
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.
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.
"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.
Super simple: run M-x gdb to bring up gdb, and then run M-x gdb-many-windows to make it look like an IDE debugger. it gives you the gdb prompt, the state of variables at any breakpoints, current threads that are running, what is on the stack, where you are in your code... pretty much anything you need from gdb. Compiling your code with the -g flag is a must though, if you want line numbers etc. for your errors/debugging.
As far as setting breakpoints and stepping through, I personally use the gdb console. However, you can set breakpoints by clicking the left margin of the line you want to break on, and I believe there is a key map for stepping through.
The benefit of this is that I can debug remotely, or when I have my development setup in a chroot or virtual environment, I can still debug from outside.
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.
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.
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.
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.
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.
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.
214 comments
[ 1.8 ms ] story [ 253 ms ] threadI never broke the habit myself, and I suspect the benefit is a lot smaller on a laptop keyboard versus an AT keyboard.
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.
First, you can use ctrl+[ to get out of insert, which means moving your hands less.
Even better (but requires customization), you can remap "jk" to get out of insert mode. Since "jk" is a combination that never comes up in actual writing, it works great. And it means you don't have to move your hands at all from home row.
And the only times I remember having to actually type jj are when I'm having the Vim keymapping conversation with somebody who asks "So how do you type 'jj'?
:)
(EDIT: uhh, the :) is a smiley, not part of the command)
Ctrl-O takes you to normal mode for a single command and then automatically goes back to insert mode.
Frankly, I find it easier to map Caps to Escape. Only problem is when you use other people's systems and you keep hitting caps lock when you mean to hit escape (Even if you're not in Vim)
But yeah, I /can't/ use others computers without getting utterly frustrated because of that. :)
All of this assume that you type 10-finger blind, but I guess if you can't even do that you have other priorities than learning vim.
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 :)
http://www.viemu.com/a-why-vi-vim.html
See "misconception #4" for this particular point.
In Vim, especially the GUI version, it's perfectly possible to just press 'i' and then putter around in your text file, moving around with cursor keys and Home/End and such, deleting, typing, and only occasionally dropping back into "command mode" (as it is often called) to delete a line, or search for something, or save the document (assuming the GUI version doesn't have key bindings set up for this already). I used Vim like this for over a decade, never really understanding the point.
As the article points out, this is completely wrong. You stay in command mode (called "normal mode" here, which gives it a different feel immediately -- it's the mode you normally should be in), and switch to insert mode only to type short bursts of text. Everything else is done in command mode.
While this seems weird at first, once you start getting the hang of it, it starts paying off big time. There are a zillion commands that do something and then enter insert mode. I used to think they were completely redundant; there's already 'i' and 'a' to do that, why have more? Because, obviously, when you spend most of your time in "normal mode", this allows you to execute a command and immediately start typing text. E.g. to insert a new line below the current one, you press 'o', and Vim inserts the line, indents it properly (if you have autoindent set), and is ready for typing.
While this is hardly heavy wizardry, once you know a couple dozen of these commands, editing becomes a very different experience. You just move through the text differently.
Anyway, the article explains this, and a lot more, much better than I can do it here. :-)
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.
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").
Modal editing is unbeatable. GNU Emacs + Viper + Vimpulse is the way to go.
I agree that Emacs allowing you to access commands while inserting text is nice. However, what are you doing in Insert mode? Hit Esc as soon as possible, my friend ;-)
Writing things?
I didn't become proficient at modal editing until I followed the advice of staying in Insert mode as little as possible, just to enter short bursts of text (and then remapping the Esc key becomes a must).
I was saying something about the post I replied to, I wanted to point out that it's easier to ease into emacs without sacrificing the chance to learn about it for familiarity.
Unluckily, you feel the power of Emacs decrease!
EDIT: Added command names.
Editing text is a solved problem. vim or emacs, pick one and get back to work.
I won't run the same test with vim, because I don't think it will be much different, and the insert/command mode would drive me nuts.
Believe me, then the programming language is the issue, not the editor.
It's especially funny, if people claim that their ide is superior, because they can automatically generate boilerplate code, but never question their programming language.
Autogeneration of code is nice when I write Java code, but even Haskell has a bunch of boiler plate import codes, as does Python and Ruby.
Search for: omnicompletion + <language>
go play with ruby and talk about the latest iDrama
Good (and as so often, kinda obvious ;) advice.
Apologies if the title wasn't as reflective of the content as I had hoped.
(Disclaimer: I do use Emacs, mostly.)
Haven't tried learning the keybindings yet myself, and I've heard VIPER isn't the complete Vim.
http://www.assembla.com/wiki/show/vimpulse
It amuses me that people actually think that's just a joke.
Emacs is far easier to script and plays nicer with other programs so there are more, more useful extensions for working in various languages. On the other hand, I find vim's modal interface faster and easier on my hands than emac's chording interface. viper-mode in emacs might be ideal.
Ergonomics. There's an emacs key chord for everything, but many of them involve two or three modifier keys.
i.e. search and replace is Alt+Shift+5, indent block is Ctrl+Alt+\
These require some finger contortions. I haven't used vim, but the impression I get is that similar commands in vim are all closer to home row so you don't have to contort your hands as much.
search & replace is % indent is > (auto-indent is =)
Emacs seems really neat, and I'd like to try out some other editors, but none of them compare to the ease of vim's modal style.
See :help motion.txt - they're in section 6. Text Object Selection. Also, just play around with them a little. For example:
If that's your text, and the cursor is at the pipe:The composability of vim motion commands is what keeps me using it.
Edit: seems actual jump selection can be finicky.
Even better, you can use b instead of ( and B instead of {, because it's easier to type.
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?
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.
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.)
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.
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.
That's a disastrous series of commands.
So C-a C-x C-s C-v C-s is just a funny way of saying C-s.
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.
But once you get past sqrt(15i*π)/2 emacs mastery, you stop using the menus and start using M-x with tab completion. There's a standard naming scheme, and usually local commands are prefixed with the mode name. And in any case, there are generally far more than fit on the menu anyway.
I'm pretty much entirely lost in a vanilla emacs installation.
This is actually one of the things which stops me from going too crazy with my emacs customizations. I have a lot (and long ago disabled toolbars, menus, etc.) but occasionally using coworkers' emacs, and using 'zile' on my OpenWRT routers and the like, means that I like to be able to remember the emacs defaults for most of the common things. :)
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.
Have a look at http://www.vim.org/scripts/script.php?script_id=1984. I love it!
Perhaps you used an older version, because the version I'm using is caching (2.22.3).
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.
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).
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.
Then again, I have a sneaking suspicion that it has to do with people liking the exclusivity factor.
They both come from a day when all UI's were text based and so it's not surprising that they offer more powerful editing models than newer alternatives, considering they've both had 30 odd years of refinement.
It's also understandable that people find them more difficult to use. The major advantage that a GUI has over a text interface is that it's more discoverable and given that most people these days have grown up around GUI's, we thus find text based UI's intimidating.
Either way, as developers, most of our day to day tasks revolve around editing text, so I'd say that using a tool that's aimed at giving us maximum textual love is a good thing.
And don't get me started on asking why, after all this time, emacs still defaults to non-CUA when it has a perfectly good mode that emulates it? That's just asking to keep new users away.
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.
If you pick up a new language (say) and are immediately fluent, have you actually learned anything?
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.)
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.
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.
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.
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.
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
Or maybe Menu, Windows, etc. keys, on keyboards that have them.
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)
I hope that answers your question.
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...
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.
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.
I like Emacs's extension model, and its "everything is a buffer" design, but dislike its modifier-heavy keybindings. I like vi's modal interface and general command orthogonality, but would rather have a persistent, extensible, etc. environment. (Also, I like Lisp, but elisp kind of sucks. And I have written, and continue to write, a fair amount of elisp.)
On the balance, Emacs works better for me, though if a synthesis of the two with a good extension language (I nominate Lua) ever comes along, and retroactively gets the ten programmer-centuries of work it'd take to match what Emacs has, I'd switch in a heartbeat.
Also: Yes, I know about Viper and the other vi-emulation modes, but people who write Emacs extensions follow the cultural standards for keybindings, etc. Including me.
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.
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.
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.
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.
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.
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.
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".
As far as setting breakpoints and stepping through, I personally use the gdb console. However, you can set breakpoints by clicking the left margin of the line you want to break on, and I believe there is a key map for stepping through.
I use Geben as the emacs plugin to connect to the debug client. http://code.google.com/p/geben-on-emacs/
The benefit of this is that I can debug remotely, or when I have my development setup in a chroot or virtual environment, I can still debug from outside.
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.
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.
One thing is for certain: Vim will never die. It's over 35 years old now, almost as old a Unix and C.
Jump to the paragraph "The Dark Side".
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.
Though I've switched over to emacs now. ;)