Learning Vim incrementally (2010)
yehudakatz.com
yehudakatz.com
The article is well written, and the authors has a good point. I don't think there are that many situations where "dive in head first" is that good of an idea.. Slip in where you can find ground, and work your way out until you learn to swim. I'd never switch off my cursor keys, I don't CARE if it's supposed to be more efficient. That's how I feel right now, maybe one day, I'll feel different, but if I do, I won't recommend any new users to do the same, that's just silly.. I mean, that'd do nothing but scare them away and make their lives miserable.
I'm very much against plugins as well, being able to reliably work on a vanilla vim install allows me to productive everywhere.
But yes, I do miss the multicursors I've learned to love on Sublime Text.
I know how to use Netrw to show a file tree but I prefer the look of NerdTree.
I also often use ctags for navigation but I'm using coc.vim plugins more and more to get code aware LFP features.
Generally I try to avoid custom mappings though so I'm closer to vanilla vim when I need to be.
Things like 'vim-tmux-navigator' saves me several keystrokes and makes vim splits work along side tmux panes. Tim Pope's 'vim-fugitive' really helps understanding the context of the changes in a git repo, or even navigate the history of changes in a particular file. Tim Pope's vim-sleuth automatically matches the formatting of a file you open.
Some modern plugins that attach languageserver features, like Coc.vim, or Ale, are really great for code completion, intellisense, automatic formatting, and linting.
Obviously vanilla vim is powerful enough to do most anything, but, it's really fun to tailor a vim environment.
1. Go to your terminal.
2. Type in vimtutor.
3. Spend half an hour.
4. Congratulations! You are now able to survive in vim, while you're by no means a master yet, you're probably around 80 to 90% as productive in vim as with a general text-editor without plugins.
IMO it's 30 minutes well spent.
This makes a lot of sense btw. Think of all the commands and shortcuts you need to know to be productive and quick in everyday programming work: OS shortcuts; terminal commands; git commands; IDE shortcuts; and now, a whole bunch of editor shortcuts _and_ commands.
And, does vim's interface help you very much with remembering what you should type in to do what? Sometimes, yes (:w(rite); :q(uit);: x(it); :w/q/x/a(ll); etc). Sometimes, not so much, no (hjkl wtf? :y? :o? Is that a smily face?).
And how much of that stuff in vimtutor are you going to use in the first week of use? 10%? 20%? 50%? The rest, you'll just forget immediately anyway. So that's half an hour that you probably can't afford and that you definitely don't need.
So taking it easy and not trying to learn a whole bunch of stuff you're not sure you need is very good advice.
I have a different opinion, but do understand your scepticism. If people would've told me this before "just type in vimtutor and 30 min. and boom you're ready" I'd have laughed at them.
As a big proponent of vimtutor, I daresay that vimtutor is taking it easy. It took me 30 minutes during a subway ride and I've tried to learn vim a couple of times, and I think I even read this article among one of those failed tries.
Yes, you learn a lot of commands, but the tutorial structures it relatively nicely. Also, they're grouped: hjkl are 4 different commands, but if you know one, you can infer the other three. The same goes for w and q. Yank and what I prefer to call "Open new line" were quite intuitive for me at the get go, but then again I had the habit of creating mnemonics.
The first 4 chapters (I think it was the first 4) already give you the super powers to survive.
Vim is indeed very unforgiving, which is why people need a tutorial.
How much stuff did I use in the first week? Well since I did the tutorial several times, I can tell from memory what I remembered initially:
The 5 essential commands:
i - Insert
ESC - Escape (aka please get me out of insert mode or whatever mode I'm in! :'( )
w - write
q - quit
q! - I really want to quit, I don't care what you do now! (and then immediately redoing the vim command with sudo vim filename.txt)
Some text editing commands (not sorted on if I'm insert or browsing mode):
dd - delete and copy (or delete and pop)
$ - goes up or down or end of line? (I still forget that)
gg - goes up or down or end of line? (I still forget that)
G - goes up or down or end of line? (I still forget that)
A - append (or small letter a)
hjkl - Home row movement, not needing to lift the finger
y - yank aka copy (as a non-native English speaker it was fun to learn that "yank" can mean copy)
x - cut
e - end of word
b - beginning of word
r - replace (not that I ever use it)
From the top of my mind, I learned about 80% of these commands back then. IMO knowing these commands makes you survivable.
Later on, I also learned a thing or two with vim visual mode. I kind of forgot that now. I vaguely remember it was something with CTRL + V or Shift + V and that you can select a block and indent it with Shift + I. I remember I went even into the vimrc file, or whatever it was called. But I decided to stick with Sublime Text and simply use this skill when I quickly need a terminal editor (oh, and also to not be annoyed by git).
As you can see, in the demonstration of my very humble knowledge, I only vaguely know what the commands do as I don't use vim every day (more like every month to touch a line quickly). But I kind of know what they do and with some quick experimentation I figured it out again.
I have the suspicion you already know vim. For other people, my suggestion is: just try vimtutor, you'd probably already have finished chapter 1 and 2 by now if you would have done vimtutor instead of reading my long comment.
OK, I accept that some users will find vimtutor helpful, like you did. On the other hand- I would never have learned to use vim if it meant I had to read 4 chapters before I could "survive" in it.
The way I learned vim was ... to not try to learn vim. This is much like the article above describes it. Before vim I was using Notepad++. At some point, I switched to vim and just did all the things I was doing in Notepad++, except I did them using vim. That meant I only had to climb the smoothest learning curve and my productivity never dropped from having to stop and search for advanced stuff.
I was a bit annoyed originally by the Mikado of escape slashes in regexes, but I got used to them reasonably quickly. Then at some point, when I needed to do more advanced stuff that I'd never have considered doing with Notepad++ [2] I looked that stuff up and learned how to do it, but only as and when I needed it.
In the first year or so I was keeping a notes file with all the weird-syntax commands that I needed with enough frequency that I wanted to keep handy, but I couldn't bother to memorise. I still occasionally consult this file, e.g. when I need to remember the syntax for look-ahead or look-behind regexes. It turns out, you can go a _long_ way without really, really having to do a lookahead.
I should say, I also tried a few vim plugins here and there, but mostly they seemed to mess up my install, so I was turned off them for good. Pretty much the only plugin I use nowadays is the excellent highlight script from the vim wiki (https://vim.fandom.com/wiki/Highlight_multiple_words). It's just perfect for highlighting logs and, er, logs.
So while I appreciate that vimtutor can be useful to some users, it is by no means the only, or the simplest, way to get to a point where you're feeling comfortable using vim.
________________
[1] The one exception is the Emacs-based editor in the Swi-Prolog IDE, which has a very good Prolog mode that actually compiles your code so it flags errors and so on. It'd take a while to do this in vim, and there's no real reason to. Although I miss being able to scroll with Ctrl+E/Y.
[2] Like using netrw to edit files directy on a remote server over a powershell remote session, which got me some impressed comments by a senior dev in my company, since everyone else just RDP'd to the server.
I'd follow it with watching some editing videos on http://vimcasts.org/ and by reading Practical Vim[1] gives a really good set of editing recipes in "pure" vim without plugins.
Finally I'd also suggest the follow up Modern Vim find out about plugins and LSP support.[2]
My go-to example for strong support is emacs' evil-mode¹, it takes a lot for it to break down. For example, it even supports things like the expression register² but then requires an elisp expression.
1. https://bitbucket.org/lyro/evil/wiki/Home 2. https://vimhelp.org/insert.txt.html#i_CTRL-R_%3D
Edit: I'm pointing out where it has fallen down for me, not complaining that the devs haven't implemented a full vimscript interpreter to attach to that binding. I love evil.
For example, you can have your own custom "vimrc", they call it ".ideavimrc" which can also read your normal .vimrc but I prefer to keep it separate.
Once in the .ideavimrc, ideavim has emulation for probably the most popular vim plugin (vim-surround) and also vim-multiple-cursor and commentary.vim plugins, you just have to enable them... set surround, etc... see more at: https://github.com/JetBrains/ideavim
But to me the best part of it is doing my own keymappings to execute IDE actions which sometimes don't even have a shortcut or menu and are just accessible by "mouse"
you can do stuff like:
:map <leader>r :action Refactorings.QuickListPopupAction<CR> (refactor this popup) :map <leader>z :action ChangesView.Revert<CR> (git revert dialog) :map <leader>f :action Tool_External Tools_Flake8 (run flake8 external tool)
supports imap, vmap as well in case u just want to trigger in those modes.
etc... this will let you use the ANY IDE action with just the keyboard and most dialogs in jetbrains IDE support CTRL+N/P for next/prev navigation in panes... not to mention you can filter most of them just by typing whatever
The fact IdeaVIM exists is probably the biggest reason I use and pay for Jetbrains IDEs, all the VIM goodness + IDE convenience.
Is vimR better?
Despite my love of vim, on the desktop, I fall back to gedit or Notepad++.
Vim and Emacs are great editors when you're SSH'd to a headless server, but they will not replace an IDE (or even TextMate). That is completely ridiculous.
At the time I switched, I'd been using Notepad++ and loved it. These days, my graphical editor is Sublime (of course with vintage mode enabled).
Vim with just a handful of plugins is a complete IDE. Vim alone is an editor.
So you should count yourself lucky that you can use vim on your headless servers -as I can, and I do count myself lucky, because I have seen the horrors of trying to edit files with ed, on Z/Os, inside TSO, on a mainframe. And it was not cute and cuddly like mistakingly retrieving xa! on the command line in vim and pressing enter, when you're not done yet with your changes and you don't have a copy. It was much, much worse.
I grant that vim is not the most user friendly, but if you take the time to learn it it can do almost everything most IDEs do, including symbol based navigation, “fuzzy finding”, search-and-replace, etc. And that’s just native Vim — some plugins make these features completely comparable with (or better than!) IDEs.
I’m convinced that modal editing is the most efficient way to edit text, and vim’s biggest feature is how tightly integrated it is with the terminal. In a GUI editor, using a terminal means either using a subpar integrated terminal (like in VSCode) or switching over to my terminal emulator to run some commands and then switching back. Since I spend a lot of my time in the terminal, this is a big deal for me.
I'm a vim user, certainly one who was alive long after "good GUI editors." My first programming was done in Visual Basic over 20 years ago.
I am hobbyist programmer and a parent, so I don't get a lot of time to do programming these days. When I do I don't like fiddling my half-baked tmux/vim setup. I just wanna write code. So I use IDEs.
It depends on what you use in Eclipse, really. But vim has plugins to do things like autocompletion, there's many ways to access console (:term), etc. It's all done through plugins, you just use whatever plugin manager to add them. It's very simple.
>I am hobbyist programmer and a parent, so I don't get a lot of time to do programming these days. When I do I don't like fiddling my half-baked tmux/vim setup. I just wanna write code. So I use IDEs.
Me too, but the day or two it took to get vim setup to function as an IDE also meant I had all the power that comes along with vim. For me it is well worth the time investment of a few hours for something I'll use for years and years and be more productive than using Eclipse. And allows me to go between my normal text editor and IDE and share all my keybindings and workflows.
I think a good trade off would be something like a vim plugin for Eclipse. PyCharm for example has IdeaVIM which is a plugin that brings a lot of the power of vim to that IDE.
I just couldn't give up all the power of vim just for the out-of-the-box IDE features like autocomplete when I can just add them to vim.
One day I had enough, I started the Vimtutor process and never looked back. No more pain since.
With this in mind, observe yourself as you work and notice which motions and actions you need most (like `ci"` in the article). Focus on these at first for those sweet sweet quick wins.
Most of the discussion here focuses on the dev-side of things naturally; but I want to touch on the Admin/sysop side.
If you are just starting out editing config files there is very little benefit to using vim over some more simple (i.e. nano)
Example: Editing an sshd_config file. Scenerio: You want to change the default port number that sshd is listening to. Both nano and vim make this singular task very easy and quick. As far as speed goes, I'd say they are close or equal to each other to finish this task.
Where vim really shines is for larger and more 'annoying' tasks.
Example: You need to iterate out a list of incrementing IPs for another service.
e.g.
192.168.0.1
192.168.0.2
192.168.0.3
...etc...
192.168.0.254
But in my experience the hands-down "it doesn't get better then this" 'Admin use' of vim is this: editing YAML files (whitespace is evil, OMG why?!?) vim can be configured to convert your tabs to spaces and all pain is ended in the universe.
Little things add up. For the odd small job, you might not see an improvement over a 'dumb' editor like nano; but the skills you learn on the small things translate into big improvements on the big jobs.
P.S. Being able to edit your editor is a HUGE benefit too. My company wants us to keep detailed track of our time-spent on each project. So I added a hotkey (F5) to input the date/time-stamp whenever I start/stop a task.
Consider this analogy, nobody needs to modify their .bashrc file or create custom aliases. But look at how much you suffer when your customizations are not there. You don't need to use anything more then nano, but the improvements scale exponentially when you do.
Every editor more advanced than notepad can be set up to do this.
Personally I don't want to do this for every single text file format I might come across.
Being able to add weird, personal features does sound cool though.
And I don't even use Vim now! Visual Studio, VS Code, all JetBrain editors have competent vim emulation plugins, so the core of my ehnanced productivity, the core and most important feature of Vim, is still paying off.
I just wish I had a spare year to learn and configure Emacs. (Yes, I have tried Spacemacs and other options, many times, and it was so confusing every time that I only believe in learning Emacs from absolute basics withut any plugins now).
I wonder how well the vi plugin for VS works alongside Visual Assist X, which is the only plugin I currently use for VS. I'll have to give it a shot when I get some time.
Ugh, this.
Arrow keys have been invented for a reason, they're good and intuitive and there's absolutely nothing wrong with using them. Same with the mouse.
The "pure" VIM ways are more efficient than ed. They're maybe more efficient some 10% of times you actually need some specific thing. But they're not better than a visual editor.
In what way is Vim not a "visual editor"?
The main problem with using Vim is that you will spend a bit of time explaining to those that don't know it very well that it's actually perfectly capable of doing the thing they are using as justification that you should switch to their current favourite IDE/editor... :P
map <up> gk
imap <up> <c-o>gk
map <down> gj
imap <down> <c-o>gj
I started learning it shortly after, despite being in time press at the time. It helped immensly. Just navigating around the code was amazing. Macros, repetition of the last edit action, increment/decrement a first number after the cursor, block editing, lot of tiny stuff that is just so good when combined.
I even wrote a bunch of vim code to help writing GObject C code, when it was still boilerplate heavy back in 2006.
This has gotta be the worse piece of advice I've ever heard in my life, second only to "why don't you march towards my line?" [1]. I've been using Vim for umm, eight years? Thereabouts. I never turn off my arrow keys. How much time are you supposed to save like that? Milliseconds? You go much faster with B, E, Crl+Y, Crl+D anyway.
Just misguided advice from otherwise well-meaning folks, that's all.
Edit: btw, how do you go through your recent command history on vim without up and down arrow? Do you have to q: and navigate with hjkl every single time? Is that more productive than pressing up arrow three or four times?
_____________
[1] Sorry guys, Warhammer Fantasy Battles reference there. See, I got a shooty Dwarf army, he's got a shooty Empire army, so we're standing just outside each other's range and scream insults at each other. His light cav mauls itself on my Slayers trying to flank my Thunderers (yeah, I don't know what he was thinking, either). He's got a Steam Tank, but I got a Lord on a shield (with a metric shitton of runes) protected by a regiment of Ironbreakers (with a metric shitton of runes) on the Tank's side. So noone's going anywhere in a hurry. So, by way of friendly advice, he says "why don't you march towards my line?". Yeah, right. So your Sniper can pick out my Lord and your Tank and Knights can sanswich my guys? You kiddin'?
Btw, he did win anyway. It turns out you gotta make _a lot_ of saves against a well-designed Steam Tank. Also, I suck at aiming artillery. But, come on. "Walk towards my line"? Do I look like an Elf or something?
The point isn't to save time (though using hjkl does that for sure), it's to make sure your hands never leave the home row, which they ideally shouldn't do very often when using vim. It makes them more natural to use for composition: "c3h" is much cleaner than "c3<left arrow key>".
Also: if you become an "intermediate/advanced" user, you use these keys much more rarely anyway: I use "w" and "b" far more often than "h" and "l" to move inside of a line, as an example. Breaking your dependency on arrow keys makes this transition easier.
Besides, it frees up four arrow keys on your keyboard up to do all sorts of fun stuff with! I have mine bound to switching windows (so "left arrow key" is moves focus one window to the left), and with modifiers they create window splits. Makes using windows in Vim a breeze!
Anyway if you've bound your arrow keys to switching windows (and if you're anything like me you have a two or three windows per tab, and a bazillion of tabs, open at any one time) then your fingers do leave the home row to go to the arrow keys anyway. So what's the point?
So, sorry but I don't agree that most users would save any significant time with disabling their arrow keys. Perhaps some users would - but that should be left to each individual user. Me, I'm used to navigating around lines with the arrow keys, I abhor hkjl navigation (I even use the arrow keys on my numpad in Nethack) and I'm perfectly comfortable using vim as my only text editor since 2011 or thereabouts, when I first picked it up.
Regular typing provides an instructive example here. Try typing a long sentence right now. If you're a touch typist, you can notice that your fingers very rarely leave the home row. Even if you're pressing shift or enter, you can basically just stretch your hand a little bit, but you can reach all the letter keys and the spacebar without moving your hands. You get into a flow where your hands remain basically fixed and the typing just flows out of you very comfortably (I'm doing it right now).
However, if you decide you need to use the arrow keys, you need to move your right hand quite a distance, and it interrupts the "typing" flow. Keyboards are designed to make this comfortable, that's why there's those little nubbins on F and J so that you always know where your home row is and where your hands are inside of it.
One of the ideas with Vim's editing commands is that editing text should become as natural as typing text is, since that's what you're doing most of the time as a coder. Imagine typing regularly and having to move your entire right hand every fifth keystroke. It would be pretty terrible.
I can personally attest that it works, and that I've very glad I rid myself of those arrow keys for regular editing. Moving to a different window doesn't happen in the middle of the "flow" (just like Alt-Tab, or changing volume or whatever doesn't), so it's fine to use them for that.
I can tell you're pretty set in your ways of how to use Vim, and that's fine: if you want to use the arrow keys, go ahead! There's no law against it, use Vim however you like. But what you're saying is essentially "all those people who say it's helpful not to use the arrow keys are lying or delusional!" I'm here to tell you that we're not. It really does work really well for us.
cnoremap <C-P> <Up>
cnoremap <C-N> <Down>
I just wish there were better guides managing plug ins for Vim in Windows! I have trouble with the new Vim 8 plug in system.
I use vanilla vim as my main editor. Today I had to search for some text verbatim, and I don't think there's a way to do this in vim: It treats everything as a regex. I'll also happily use mouse support, and really hate the bad support for the clipboard in vim. I have spend multiple afternoons on getting this to work properly and it still doesn't. So sometimes you just have to take your loss and use another editor for something.
you can also use \< and \> (beginning of word, end of word) for easier phrase matching... /\<my phrase\>
[Actually I mainly use vi, but I believe it's the same program]
I like many of the Jetbrains editors; but for a small job, if I don't have Idea running, it's quicker to launch a terminal.
I tried Emacs. I was frustrated and confused and felt stupid. Then I realized I had so many other tools at my disposal, I'd just use those instead. Here I am, 10 years later, happy and not feeling stupid at all! ...but I don't know Emacs.
And don't feel compelled to offer my experience on Emacs other than I struggled to learn it, but plenty seem to find it amazingly powerful. Good for them.
Can anyone tell me what I would gain over Pycharm (when most of my work is done there) as the learning curve seems steep?
What I mean is that it's one of those computer skills that, after you learn it, even watching over the shoulder of someone who doesn't use it is painful.
As for vim vs pycharm, I wouldn't advise to switch. I would advice to find vim emulation for your current editor (vscode's is superb).
This gets especially convenient if you work with multi-language projects, where you would otherwise find yourself switching between programming environments for a single task.
Both Pycharm (and the JetBrains core IDE) and Vim have large feature sets and those feature sets can be extended via plugins. So saying what you would gain from one to the other is not straight forward. You gain some things and loose others.
For example Vim keeps it's undo system as a tree whereas most GUI apps keep their undo commands as a stack.
i.e. if you have series of edits and you undo 2 and then make a new change the other two edits are lost. In Vim they aren't, the tree of edits can be navigated at will.
Assuming that undo tree is a useful feature to you (it is for me) I'd have to do a good search of Pycharm plugins before I can say it's a definite advantage of Vim.
Equally you might find that Pycharm has some code aware feature that Vim can't provide via an LSP plugin or VS Code extension in which case you'd want to stay using Pycharm.
The main advantage of vim to me is homogeneity across different platforms and languages. Oh yeah, and the next question is do you love your terminal? Are you the type of person that would browse the web with your terminal and write ToDo lists in your terminal? If not, again Pycharm may be the preferred candidate.