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.
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:
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.
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.
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.
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.
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 ;).
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.
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 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.
"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.
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.)
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?
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?
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 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.
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.
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'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.
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.
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.
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.
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.
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.
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.
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.
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?
'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
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.
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. ;-)
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.
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.
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).
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").
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.
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.
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.
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.
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. :)
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.
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.
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.
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.
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. :)
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'?
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
Totally correct, my assumption is that Apple is mad that you can install apps without their approval and fees, so they won't bother adding a real package manager even though it's an obvious shortcoming.
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.
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.
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)
> 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
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.
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.
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.
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?
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.
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.
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.
Also, I agree that trying to refactor (say) C++ with awk would be hopelessly quixotic. I'm not an idiot. (I have written parsing and static analysis tools for an in-house language, though, just not one as screwed up as C++.) I was explaining the historical reason for vi lacking such features - grammatically ambiguous, overloading-heavy languages that combine static typing with OOP hadn't been invented yet.
I think it's bad design to have refactoring tools be a part of the editor, proper, rather than as a standalone tool the editor calls. It's more a matter of static analysis (or runtime introspection) issue than editing per se.
As someone about to open-source something that does Java refactoring from the command-line (as a small part of a larger research project related to optimisation) I feel like I ought to respond. :)
You make a good point about refactoring. It's useful, and I should do it more. But this comment goes a bit too far:
> [people edit projects, not text, therefore] a good IDE will always be better than vim
This is an unassailable assertion. If anybody manages to come up with an example in which Vim is better than an IDE, it is always possible to respond with "that's not a good IDE", possibly with qualifications ("you shouldn't be editing Java in that IDE").
One possible response goes to the definition of "better": I contend that Vim is, in fact, a better environment for creating, debugging, and generally editing files. This is actually a large part of what I do, so I appreciate it. I have been using Eclipse quite a bit recently, because it's the standard IDE for Android app development, and while it provides some great refactoring tools, it is not nearly as good as Vim is for actually editing code. I don't really understand what you mean w.r.t. "formal grammar": even Vim and Emacs can be trained to do things that rely on language-specific syntactic knowledge (examples: code completion, code folding, context-specific search). What's missing in non-IDE editors is a concept of a "project", and semantic knowledge for refactoring. That is not the same as grammar.
A command line java refactoring tool? That would be cool. Is it possible to extend it to other languages? Do you have a link - even if its to a "coming soon" page?
Let me reduce "good ide" to IntelliJ or Eclipse if that helps.
By "formal grammar" I mean that both Eclipse and IntelliJ have full Java parsers. So they can successfully rename a method on an interface, all its implementations and all its uses. This can be done if and only if the tool can correctly identify which text symbols represent a class, interface, variable declaration and method invocation, and further it can infer the type the variable in a method invocation using information from that variables declaration, even though it may be in another file.
That needs a parser. So you are correct in that you don't have to write a formal grammar to do it. You can hand role your parser. I used "formal grammar" to imply a level of complexity. Does vim have a tool of such complexity?
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.
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.
A use case for "5dwelp"? Teaching my roommate how vi's interface works, six or seven years ago. It was the first example that popped into my head. (I told you it was arbitrary. I switched to Emacs ~4 years ago.) The real point is that almost the entire vi interface sensibly combines that way, like APL operators. [quantity] [operation] [movement].
If I still used vi regularly, I probably could have given you a better example. Actually, I couldn't, but my fingers could have. :) It had all moved to muscle-memory.
Emacs's interface is a bit more cumbersome, but it's also easier to follow it with, "...and from now on, call that X and add it to the interface".
The real point is that almost the entire vi interface sensibly combines that way to operate on words, lines, paragraphs, regexps etc. Whereas a good IDE works on that which the words, lines, etc represent: i.e. a code dom.
Actually, "words, lines, paragraphs" also includes statements, function calls, class definitions, and the rest of the "code dom", in a language-specific manner. Not so in nvi (a barebones vi), but definitely in vim.
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.
no matter where your cursor is (inside the parentheses), and no matter how many words are there. No visual feedback is needed, since you know what the command is going to do. Can your C-w do the same? I don't think so.
This is much ado about nothing, however. Plugins to get Vim-like commands in IDEs do exist. So what? The power of advanced text editors comes from this: they don't do too much, and talk to other tools, and you can compose them in a modular way. Talk about knowledge reuse. IDEs are monoliths, and refuse to talk to outside world... the opposite of modular design. Isn't that ironic? Where is your IDE when you need to edit a blog post? Or when you need to do a big text munging? Your editor will be with you wherever there is 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.
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.