Step 1 for those who really want to boost productivity (but let's be honest, most of us don't!): forget about all those plugins that are time sinks to configure and integrate with each other, about obscure tweaks that take half a day to get right, and about elaborate .vimrc's that take you so far away from 'standard' that you're crippled without them. Stick to a fairly basic standard install and a .vimrc of 50 lines, tops.
I've been using vim for 15+ years now, since late 1990's. I use viemu in Visual Studio and I've written code in 10+ languages in vim. I've written non-trivial vimscripts and integration tools with other parts of my workflows over the years. I love how comfortable it feels, and I feel crippled when I have to use a 'normal' editor; like walking with a little pebble in your shoe - not a big a deal enough to prevent you from doing anything you could otherwise, but still damn uncomfortable.
With that said, I'm not convinced that I've actually saved time with it. I shudder if I think of the many man-days I spend 10 years ago on getting this and that plugin working, tweaking settings and keybindings for things I use twice a month tops and automating things that I could have done manually 10 times faster. It's not like regular editors are that much slower to use. It felt like throwing off a yoke when I dumped all those plugins so that I could focus on writing software, instead of tweaking the editor so that I could write programs with a few keystrokes.
> and about elaborate .vimrc's that take you so far away from 'standard' that you're crippled without them. Stick to a fairly basic standard install and a .vimrc of 50 lines, tops.
I think this is terrible advice. While it is true that one should avoid getting lost down the plugin rabbit hole, for many of us, the whole point of Vim is that it is a configurable, composable editor.
As for being "cripped" without my vimrc, well, moving tiny text files around is pretty much a solved problem at this point. And as a developer, I'd prefer to optimize my 99.9% of the time environment, and not worry about the .1% of the time I'm away from it.
I do, however, recommend that your vimrc is something you should build up over time, understanding what you are putting into it, rather than grabbing some big off-the-shelf framework and using it without understanding what is going on.
I started feeling the same, about the configuration time sinks ... my solution was to create ansible-configurable docker images with everything setup ... so I can throw away and recreate the images once a month, when the plugins get screwed up (which they really do, about once a month or so!):
I've been cutting down on plugin use and esoteric mappings because of similar reasons but 50 is really small. I still hover around 10ish plugins, some of them are language dependent to help with indentation. Some of them just aid in intergrating with tmux or git, make it just a bit easier to open a file (ctrlp), or some show syntax errors.
Without stuff like that I'm still fine should I find myself on a remote machine. But I don't see an issue with making myself more comfortable than just being 'fine' on my personal setup where I spend most of my time.
I think the key is to vet your plugin and mapping choices to ones that expand upon vim in some way and avoid those that override core functionality or prevent you from learning them. If you do that you should be fine without imposing an arbitraty vimrc length.
I've done major swaps between Emacs and (n)vi over the years (currently all vi all the time now, but if you caught me last year, I was ~6 years into my Emacs phase...) -- anyway: the fussing and portability is what kept me from developing custom elisp scripts that I couldn't be guaranteed to have sitting down at every computer, and what now keeps me in nvi, and my nvi usage pretty "vanilla". It's not clear to me if its only the fear of getting caught w/o a custom environment is what's keeping me from developing that environment, but regardless, my env is vanilla.
I keep my vimrc and .vim/ in Dropbox (and backed up other places) so I'm pretty much planning on using Vim for the rest of my life...
This also means when I had a computer outage and borrowed my wife's MBA without an dev tools aside from what came with OS X, I logged into dropbox, copied my .profile from dropbox and magically had a working, customized Vim on her computer. After a Git clone I was productive in maybe 20 minutes tops. Just imagine trying to do that with visual studio (i've tried, there goes a day).
Er, I've done this with Visual Studio... just export your settings as an XML file, import them in the new install, and of course install VsVim[1], and you're good to go.
2. I install VS quite a bit, it's not that long at all. More time than sublime et all though, agreed. I usually have it as my "parallel" process while I go clone my repos.
It's definitely a pain to install those plugins. I spent a week customizing vim when I decided to move from WebStorm back to vim. I got 95% of the functionality I have in the IDE. If you have the time, I would definitely recommend spending it. The more time you invest in vim, the more it pays you back.
If I had to choose 1 plugin, I would choose Unite. It's great for development projects where you have lots of files. Especially when you set up key bindings. Having 3+ files open at the same time (model, view, controller, tests) is a pain to have to type the paths each time. Often times you need to open them have them open at the same time. Having quick keybindings to open new windows and navigate them are really a blessing. The default controls are too much of a pain for this workflow.
It really depends on what type of plugins you're talking about.
The ones that highlight syntax errors in python, or js, or that spit out compilation errors for C are a must, and one of the most important features for me.
The plugins that take hours to configure, and let you press on key instead of three for some infrequent action: yes, avoid them. No matter how fancy they look, and how well someone tries to sell it to you.
CtrlP is also a must for me. Instantly open any file, even if I vaguely recall it's name. And no configuration necessary (though you can optionally tweak it a bit).
Well said gramps. People don't get that juggling text "more productively" is not what makes or breaks a programmer. What makes or breaks a programmer is their ability to think productively, i.e. how well can you formulate a plan of attack for a given problem before you get to the keyboard, and there ain't no tool out there that can make that any easier.
I've also been using vim for 10 or 15 years. I typically use a couple of plugins (1-3) and that's it. I leave the key bindings alone. I've never liked vimscript and have only done a few things there. Luckily I started that way and stayed that way, so vim actually has saved me time.
In my 6 years of coding and writing LaTeX in Vim, I have found that the greatest boost to my Vim productivity is learning all about the vi and ex foundation of Vim. My Vim knowledge applies 100% to any default Vim installation on a modern distro, and my vimrc contains mostly trivial tweaks.
This means using :normal and macros instead of :s for most of my search/replace actions; using H, M, L, {, } to navigate quickly in the lines visible on the screen, and using f/F/t/T/;/,/% to navigate quickly within a line.
I would say that 98% of my autocomplete needs are fulfilled by token completion (:help i_CTRL-N) and line completion (:help i_CTRL-X_CTRL-L).
I frequently use the command-line window (:help c_CTRL-F) and listing matching names (:help c_CTRL-D).
I specifically don't have mappings that involve the leader key, and I don't use the Ctrl-P plugin or a package manager or anything like that -- I honestly don't think that mapping <Leader>w to :w<CR> will make me any more productive in Vim.
Suppose a range of lines contains function calls in some programming language:
i = foo(a, 42, 1)
j = bar(b, c, 100, 2) # this is a comment (well, duh)
bazbar(etc, 3)
You want to edit the last parameter in each function call -- change it to 'hello'. I have two ways of approaching this: macros (interactive) or :norm (less interactive).
1. Put your cursor on the first byte in the first line, type qq to record a macro of your change, q to finish. Select the rest of the lines in visual line mode and type :'<,'>norm @q to run the macro on each of the remaining lines.
2. Select the lines in visual line mode and type, for instance,
:'<,'>norm %F,ws'hello'
This is the "non-interactive" version of the above since the macro keystrokes are given directly to :normal. Pro: ability to undo keystrokes unlike when recording a macro. Con: cannot actually see the effect of the keystrokes (but with practice, this is not a problem).
(Note that colon in visual mode automatically inserts the :'<,'> so you only have to type :norm ...)
I find the declarative nature of regexes/:s to be too restrictive -- I much prefer the operational nature of macros/:normal, since that lets me make the change I want directly, without me having to phrase the change as a regular expression.
I could also use CTRL-A in normal mode to increment the last argument in each line:
:'<,'>norm %b^A
(where ^A is the literal, typed CTRL-V CTRL-A)
I feel like a wizard whenever I use :normal in a non-trivial manner.
I normally include a move to next line part in my macro and then guess at how many times to run it (20@q, repeat until I get it right). It's actually the main reason I often don't bother using macros.
@@ applies the previously applied macro, so after applying the macro (including the move to next line, but see below too) you can you just hold down @ and quickly go through as many lines as you need. If you overshoot, you can just press u a few times.
Another tip: when you forget to add the move to next line to your macro, you don't have to start over. You can append to a macro, just use the upper-case register name instead. So to append a down and move to beginning of line to macro 'a', you'd type qAj0
Using :norm, this transformation can be achieved in the following way:
:'<,'>norm I{^[eldedecw, "^[A"},
(where ^[ is a literal escape, typed CTRL-V ESC.)
Anecdotally, it is faster for me to type up such a line than an equivalent regular expression, since I use vi normal mode commands much more than regular expressions.
I would have piped this through awk, but this is probably better done with macros. Thanks for taking the time to elaborate. I will definitely give macros a try.
You need to know how dw, de, cw, ce relate to each other, when the cursor is on a token character vs. a whitespace character, and so on, in order for this to be truly useful -- but luckily, ordinary practice with those commands in Vim can lead to an efficient internal idea of how it works. "You get used to it, though. Your brain does the translating. I don't even see the code. All I see is blonde, brunette, redhead."
this is awesome, can you please suggest some resources for me, a long-time basic user of vim, ( know a lot of commands for actions, but not the underlying relationships?
Something i've been using more lately is Ctrl-R + Register. Great for inserting text in command mode. For instance, you can do this to insert your recorded macro (if it's in register q) as a norm command:
:norm Ctrl-R q
I would have almost simply started recording a macro, convert the first one using as many idempotent normal mode commands in place of insert mode commands as possible, and simply replayed it. Thanks for the idea.
As a side note, I love how Vim is basically a functional programming language for text editing.
Well you're leaving the middle columns there, then on your first keystrokes it would be acutally {+down+left as Sublime does not put cursor back at beginning of line when going down. In all I used 26 keystrokes in Sublime, and 27 in Vim. Also, if you understand Vim's vocabulary, the "cognitive overhead" is, as you put it "far less" in Vim's favor. IMO.
I am sorry, but I don't know any resources... I have collected a few things on the following page: http://users-cs.au.dk/rav/vim/
Basically, I achieved my wizard-level C++, Vim and Git knowledge during my three years as a part-time student programmer in the basic research center MADALGO. I took the time to study the documentation (respectively the C++11 draft, :help and the git man pages) whenever I was curious. For Vim in particular, I made sure to eliminate all repeated keysmashing in my daily workflow, which "unfortunately" required me to learn about macro wizardry.
My only advice is to keep practicing, to keep trying to spot inefficiencies in your own workflows, and to actively eliminate these inefficiencies by studying the Vim help pages.
Over the years, I've got a lot of mileage out of "Learning the vi and vim Editors" from O'Reilly, and web pages like http://www.lagmonster.org/docs/vi.html. Practicing and testing compositions based on what you learn from these will go a _long_ way. Try new ways to move (by screens, by sentences, by blocks), test using your buffers, experiment w/ transforms. Then, one day, you realize you're pretty good with vi.
I usually use the asterisk to search for the token under the cursor, edit the sought token using cw and then n.n.n.n. to replace later occurrences. I don't see how the mapping makes this more efficient.
Wow I have only been using H and L, and only because of you have I come to know M, {, and }. Thank you!
But would you mind giving an explanation as to what the other things you listed do (f/F/t/T/;/,)?
From just playing with them, it seems like f goes to the next character that you type and F does the same but backwards. t/T does the same but instead of going to the character it goes one before/after.
fx moves the cursor to the next occurrence of x, and semicolon repeats the search. To repeat the search in the opposite direction, use comma. 4tx moves the cursor right before the 4th occurrence of x right of the cursor in the line. F and T move backwards instead of forwards; in that case, semicolon continues moving backwards and comma moves forwards (similar to / ? n N).
It takes a while to get used to, but it has made me much more efficient compared to when I just pressed wwwww or eeeee or bbbb to get where I wanted in a line.
I also make liberal use of '/' to get around. Sometimes the bit you want is a line or two down so 't' doesn't quite cut it.
I use t / f a lot when cutting things, though there's probably a better way (from the article, I just discovered gn to visually select the next item matching the previous search).
eg, I might have a name that I want to replace in a couple of spots so I find it easy to do something like:
/AIDOS<CR>cfSNEWNAME<ESC>n.n.n.
It's generally when it's a bit less calculated. If I knew I was replacing a load of stuff I'd use :%s/AIDOS/NEWNAME/gc
when I learned about f and F a whole new world opened up for me. It never ceases to amaze me how amazing vim is. Another quick thing I recently learned (yes, novice vim user here) is stuff like this
\includegraphics{test.png}
if you stand inside the curly brackets and type ciB (change in Brackets) you get this
\includegraphics{}
with your cursor active inside the brackets, just awesome ..
nice. I was wondering how one would accomplish the same with parens, i.e. ci(. Why does this work? It doesn't seem to match the usual building of commands. I mean this obviously isn't c command followed by i command followed by paren. Is it just special?
I don't know if I am understanding your question correctly.
I read 'ci(' as change what's inside parents. I read 'ci{' as change inside braces. 'ca(' and 'ca{' grab the parents and the braces as well.
=========================
These combinations work for (d)elete as well. If your cursor is over the 4th letter of a 6 letter word, 'dw' will delete to the end of the word. 'diw' on the other hand will delete the whole word. (I've never tried 'daw' although I know 'da(' works)
right. I guess what I meant was 'c' and 'd' are usually followed by movements, so stuff like 'dt)' makes sense to me. 'i' on the other hand is not a movement, so the behavior of 'di)' was surprising to me.
It's because 'iw', 'aw', and the like are commands of their own when an operator like 'c' or 'd' precedes [1]. So 'di)' is interpreted as 'd' followed by the 'i)' command (if I'm interpreting it correctly!), not as 'd' followed by 'i' followed by ')', which is nonsense.
I hope that was clear - just trying to understand vim better :)
> I specifically don't have mappings that involve the leader key, and I don't use the Ctrl-P plugin or a package manager or anything like that -- I honestly don't think that mapping <Leader>w to :w<CR> will make me any more productive in Vim.
I'm not as much of a purist, but that line jumped out at me too. For me, the attraction of vim is primarily in raw out-of-the-box editing power and ubiquity. Relying on custom binds for basic actions really hurts the ubiquity half of the equation. And really is :w<CR> where one wastes time in vim? If I wanted to customize everything I'd probably switch to emacs.
Still, it's interesting to see how many different ways vim can be optimized according to individual workflows.
While all of that is correct, it's also the core of vim philosophy that using 2 key strokes instead of 3 is what speeds you up. That said I also haven't used too fancy configuration or mapping or plugins in vim yet because I fear I don't have them when I ssh into another system, which happens quite often. But I have to say that I use a few aliases in git and that speeds me up a lot, as long as I stay on my system.
"%" works fine for moving around, but when I use it to edit it always surprises me, which direction it goes. I almost think vim is psychic, because "%" goes the wrong direction for me at least 80% of the time. There must be a deterministic rule governing this, but can anyone explain to me what it is?
Find first brace to the right of the cursor (be either an opening or closing brace) and jump to the matching one. If the cursor is at the beginning of a line of matched parentheses, % will go to the closing parenthesis of the first group, as in my example in a cousin comment.
I'm all for bending your text editor to your will, but a few of these tips gloss over the core of vim: the shortcut language it offers and the composability of its parts of speech [1].
For example, remapping the paste key to paste + move to end is cool, but `ppppp` to paste 5 times circumvents vim's killer repetition. Want to paste 100 copies? (hopefully you do this rarely). Just type `100p` and you're done. I won't bother typing out the obvious sequence of repeated `p` presses, but you get the drift.
Also, remapping v to progressively select larger surrounding text objects will keep you from learning that you can perform any action on the 3rd parent curly braces by following the action with the text object `3a{` or `3a}`. Select it: `v3a{`, delete it: `d3a{`, comment it out `gc3a{` ([2]), whatever. If there's an action in vim you can perform it on a text object which can usually start with some count.
I really do mean language, too. When I'm using vim, I feel a lot more like I'm communicating with my computer than trying to figure out how to do what I want to do.
The actions are there: delete, change, select. The direct objects are there: braces, this line, line number N, end of this word, the next character C, this paragraph. The prepositions are there: inside, outside, up to (inclusive, exclusive).
Heck, the sensible defaults feel a whole lot like the "understood" words that you can leave out of sentences. Instead of "navigate to line 30", you can just use the shortcut for "line 30" (30G) and be done.
One of my favorite things about vim is the number of times I've literally been surprised that vim didn't read my mind and go where I was looking. Once you're familiar with the different pieces, it's so good that you might expect it to read your mind.
> I really do mean language, too. When I'm using vim, I feel a lot more like I'm communicating with my computer than trying to figure out how to do what I want to do.
I tell people learning Vim or Emacs that they should treat it like learning a new programming language -- a programming language for text manipulation. (In particular, don't attempt a first project in C++ while writing your first report in LaTeX, both in Vim for the first time -- it will not be a pleasant experience!)
This post has some valuable tips (I'm probably going to try out <Space> as a leader), but one or two near the start rub me the wrong way in terms of how I use vim and how it's my impression that it's intended to be used.
>It seems like vvv is slower than vp but in practice I don’t need to think beforehand what to select, and what key combination to use.
The way I've always used vim and always thought it was intended to be used is that you do think beforehand. You sit at your editor, think about what changes you want to make, and then key in a set of precision commands in vim-editing-language and it happens.
>This way v replaces viw, vaw, vi", va", vi(, va(, vi[, va[, vi{, va{, vip, vap, vit, vat, ... you get the idea.
I kind of like the precision of having all of those different things, and of course the option of using them for more than just visual select but also change, delete, and so on. Although I suppose this doesn't remove any of those keymappings, I must protest remapping Ctrl+v: I can't even use an editor without block select.
I imagine there's a plugin (or even builtin feature) that at least generalises "s, (s , [s, tags and things of that sort though.
>Stop that stupid window from popping up:
>map q: :q
I know it's a weird and irritating thing to have that window pop up when you meant to quit, but it's actually a very neat interface: a whole vim buffer for recomposing commands and your command history for later execution (almost acme-like). Give the poor guy a chance.
As a counterpoint to what I've pointed out above, I'd like to recommend Drew Neil's [Practical Vim](http://www.amazon.com/Practical-Vim-Thought-Pragmatic-Progra...) to anyone who hasn't read it already. It's got a lot of great content, and really goes a long way to explain vim's quirks and methods of doing things.
One of the useful tips I learnt from that was the ex command "normal", which allows you to execute a string of normal mode commands over a range of lines. So, for example, you can append a semicolon to each line in a visual selection by entering
:'<,'>%normal A;
A small thing, but one that I've used a lot since learning about it.
mapping. I do this all the time ("+p). It's weird because I tend to go through waves of realizing "Oh! I can just remap that!" I feel like I have fairly good vim skills but somehow always forget I can keep making it more efficient than it already is.
I've got vim set up to use the system clipboard automatically. Want to visit a URL in a readme file? yiW, tab over to chrome (with vimium), hit P to open it in a new tab. Want to add a URL to documentation? yy it from chrome, tab to terminal, p it in.
It is a long long time ago that someone taught me something really new about vim and used plugins that are not just fancy (looking at most status line plugins or nerdtree) but actually seem to improve productivity in a vim-ish sense. Kudos!
python-mode or jshint2.vim? I don't think that they are "just fancy. Bringing linting into the editing window is more helpful (to me personally at least) than having a separate process running with it.
(Note: I turn rope off in python-mode because it's horribly inefficient, and sometimes causes Vim to delay reacting to user input)
This is one of the best "how to boost you Vim productivity" articles I have ever seen. It really gets to the heart of the types of customizations that a lot of people don't consider that make a massive difference.
Probably because that doesn't fit well with touch typing. A great thing about vim is that you can do everything as a touch typist, without reaching for the outlying districts of the keyboard (assuming you've remapped the escape key to capslock, or learned to use ^[, or mapped it).
Additionally, on many keyboards (specifically Apple keyboards), you have to hit a modifier key plus the function key. For example, you have to hit Fn + F1 to get F1 because otherwise it's the "Lower LCD Brightness" hotkey. This makes them even less useful.
Not always useful if e.g. you're locked out of the BIOS, the setting constantly auto-resets for no apparent reason, the keyboard is partially broken.
The sad thing is that I've personally experienced all three of these problems. #%^$ whoever decided that the Function keys should be brightness etc by default.
Does Apple not offer Fn Lock? Most keyboards in the last many years seem to be going this way, but it's always easy to switch it off. I certainly press F5 more often than change brightness.
The only F-key I can hit reliably without looking down is F5, which comes from years of browser use & web development, and a slight gap there on my keyboard.
Perhaps it could be learned, but I haven't learned it yet in ~20 years of typing.
A few of these are good suggestions but I can't live without C-v, whether I am already in visual mode or not. Block selection may not be used that frequently but when it is, it's a lifesaver.
I use block selection so often that I've switched the mappings in my vimrc. I have v mapped to visual-block selection and ctrl-v mapped to visual selection. It's very rare that I miss normal visual mode as I use block and line selection more than anything.
I have hacked my tabline to be a list of my open buffers. It still functions as a tabline, for those of you who use tabs, but it's kinda nice to see all my open buffers in a nice list across the top of my screen.
I disliked the part about setting up Vim on servers. Do you really want to be adding all the dependencies for your editor on every server? I'm an advocate of using the netrw plugin to edit over ssh directly and avoiding logging into servers when not necessary.
`kj` has worked really well for me (except, actually, when trying to write a blog post about a recent trip to Reykjavik, but that's the one time it's bitten me versus the shitton of time it's saved). I also have `zkj` mapped to `<ESC>:w<CR>` to save AND exit insert mode.
It's the combination jk (or kj) that is set up to switch from insert to normal mode. The idea is that this combination rarely occurs in English text. The drawbacks are a slight delay in cursor movement when typing j or k as vim waits to see what comes next, and momentary confusion when you inevitably need to actually insert these sequences.
I much prefer mapping Caps Lock to Escape at a different level (with xcape -- caps is both my i3 modifier and my Escape key). That way, when I SSH into something and use vim or a shell it still works (or when I vim as root), and anything with a vim mode will just work.
I had jk mapped for a long time and thought it was safe. Then one day I actually had to type it as text, and it took me a moment to figure out what was wrong. I'm retraining myself to use ^[ now.
I don't think the speed hit you take when you actually have to type 'jk' should be a dealbreaker. It rarely comes up, and when it does, you can use e.g. '<C-v>j<C-v>k' or 'jjkak'.
This is great. One thing the author should do is remap enter to something better than "jump to end of file." I remapped mine to ":w<CR>" to save the current file, and it's stuck.
Does anyone have any advice on bindings to change split size? Ctrl-w + and Ctrl-w - just don't work well, and my current configuration shadows Ctrl-a, which I really would like to avoid.
I rarely resize windows, but when I do, I set mouse=a and use the mouse to drag the window borders around. There's also CTRL-W _ (underscore) to maximize the current window and CTRL-W = to make window sizes equal.
I'm in the same boat, rarely re-sizing windows, and I'd do the same thing, but I use Tmux and terminal Vim and using the mouse there just doesn't work in my terminal emulator. (I use st[0] on Linux. It probably would work in iTerm on Mac, but I haven't tried.) It also may not work due to Tmux being configured with mouse support.
Also, did you know that Ctrl-w | maximizes the a window horizontally? So if you have splits open above and beside you ctlr-w _ ctrl-w | will maximize your current split.
It might be dangerous, and I recognize it's one of the less portable aspects of my (old) vimrc, but I used to set up and down arrows to split resizes, and left and right to prev/next buffer.
I read the help, it's pretty awesome. There's a few bindings in there that I had no clue existed, like Ctrl-w {H J K L} to rotate windows, and ctrl-w f to split window and edit the file under the cursor. My problem is that the default bindings are just a pain to type. Ctrl-w + is a lot of work when you have your window navigation bindings set to CTLR - { h j k l }
So far the only issue was some slowness when it uses xsel over ssh. I don't think it should take that long because of network alone. Otherwise - it's very good.
I've been using vim for 15+ years now, since late 1990's. I use viemu in Visual Studio and I've written code in 10+ languages in vim. I've written non-trivial vimscripts and integration tools with other parts of my workflows over the years. I love how comfortable it feels, and I feel crippled when I have to use a 'normal' editor; like walking with a little pebble in your shoe - not a big a deal enough to prevent you from doing anything you could otherwise, but still damn uncomfortable.
With that said, I'm not convinced that I've actually saved time with it. I shudder if I think of the many man-days I spend 10 years ago on getting this and that plugin working, tweaking settings and keybindings for things I use twice a month tops and automating things that I could have done manually 10 times faster. It's not like regular editors are that much slower to use. It felt like throwing off a yoke when I dumped all those plugins so that I could focus on writing software, instead of tweaking the editor so that I could write programs with a few keystrokes.
So yeah, that was gramps' advice I guess...