h/j/k/l (movement keys)
i (insert mode)
esc (leave current mode/go to default state)
u (undo)
>> / << (indent, unindent)
dd (delete line)
yy (copy line)
p (paste)
v (visual mode, used to highlight stuff)
gg (go to beginning of file)
G (go to end of file)
r (replace the char under the cursor with the next char entered)
% (jump to next paren/bracket, or if on a paren/bracket, jump to matching paren/bracket)
w (go to next word)
dw (delete word)
cw (change word (deletes the word then goes into insert mode))
A (append (goes to the end of the line and into insert mode)
0 (go to beginning of line)
$ (go to end of line)
/some_word (searches for some_word, hit n to jump to the next occurrence)
?some_word (searches for some_word, in reverse direction)
:%s/regex/replacement/g (replace regex matches with replacement)
:q (quit)
:q! (quit without saving)
:w (save)
:wq (save then quit)
:x (save then quit)
:set blah (turns on setting blah)
:set noblah (turns off setting blah)
e.g. 5d deletes 5 lines. 5y copies 5 lines. 5> indents 5 lines. 5j jumps down 5 lines. Some common command combinations:
%v%> (jump to next bracket, go into visual mode, jump to next bracket (highlighting everything in between), then indent it all)
ggdG (jump to top, then delete everything to the end of file, (clears a file))
ddp (deletes a line of text and then pastes it (below where it currently it), thus this transposes two lines)
EDIT (joke):
Q. How do you algorithmically generate a cryptographically strong random string?
A. Put a newbie in front of vim.
ci"
ca)
So you can be anywhere inside a quote and do "change inside quotemark" and it'll delete everything inside and leave you in insert mode. "around" would delete everything inside and the quotemarks.
These can be used with other things, parentheses, square brackets (and I think some plugins extend it to html tags and the like).
Of course, you can swap out c for d, y or any of the other verbs.
Working in clojure and deleting everything inside a particular level of nested parentheses is awesome.
On a related note: I've never understood the fixation with being able to enter numbers into vim. I almost never know the exact number of characters or lines I need to move/delete/indent/whatever, but key repeat is fast enough to "replay" or redo an action that I'm likely done with it before I would have figured out the exact number.
I like the general concept of being able to "program" an editor with strings of commands. But in practice I'm much faster with the GUI approach. As a bonus, all of the commands I need to know to edit text in a Firefox window, or in any other window in a GUI-based OS, also follow the GDI standards, so I get a base level of efficiency in whatever program I need to enter text in.
VIM is great for editing over ssh. When I have no choice. But I feel seriously handicapped having to use ONLY the basics to move around, copy, paste, and edit, when I'm used to having much more powerful functionality at my fingertips.
As for knowing the number of lines you need to jump, either do :set number and be quick at math, or you can modify the numbers to be relative to your current line.
I took me probably a week to be able to actually get anything done in vim, and a month to prefer vim to anything else.
That being said, I know far more commands than the ones I listed. Those commands got me to my first month, though.
Numbers are also a good way to limit haphazard movements that have nothing to do with what you are trying to do. Do you want to "move the current line to after line 13" or do you want to "move to the first column of the current line, select to the EOL, cut, move down, down, down, down, down, down, open a new line and paste"?
:t13<CR>
Do you want to "group together all the variable declarations scattered around the current function at the top" or do you want to "move your cursor to the line of the next variable declaration, move the cursor to the first column, select to the EOL, cut, move up, up, up to the top of the function, open a new line, paste and repeat that nonsense for every variable declaration in that code block"?
vi{ " visually select the function
:g/var/m?funct<CR> " move every var declaration right under the function declaration
You have many "more powerful functionalities" at your fingertips. Being lazy or incredulous doesn't make Vim an overrated tool, it makes you an inefficient user.
Using Vim efficiently is a very valuable goal but it's not a goal that can be reached without a little bit of work. You won't get any benefit if you refuse to do any investment.
"Normal" editors/IDEs don't require that much learning because they don't offer much in the first place. You can become a TextMate/Sublime Text power-user in a week because there's not much to them. Becoming a Vim power-user is a life-long experience: it's your choice if you want to take that path or not.
That said, nobody (I hope) is forcing you to like it or learn it. Keep using what works for you, there's absolutely no problem with that.
For ex: working on an HMTL+CSS+JS documents all at once. Assuming smaller screen where I can't have a vsplit screen.
How to I jump between them quickly? Buffers/tabs?
I love VIM but I haven't found a good tab/file switching solution. In Textmate tabbing was straight-forward. VIM doesn't seem well suited for tabs (especially with things like NERDTree and control-p).
nnoremap <Leader>b :buffers<CR>:buffer<Space>
nnoremap <Leader>n :bn<CR>
nnoremap <Leader>p :bp<CR>
So I'd give that a shot. If that doesn't work for you, try just ":tabe <file>" for your three files, then ctrl+pageup, ctrl+pagedown (or gt, gT) to quickly switch between them.
https://github.com/kien/ctrlp.vim
For switching quickly between the 10 most recently used buffers:
https://github.com/vim-scripts/LustyJuggler
I suggest adding this to your .vimrc (the default mapping is <Leader>lj; my leader key is the spacebar, and I find space space to be much better):
let g:LustyJugglerDefaultMappings = 0
nnoremap <silent> <Leader><Leader> :LustyJuggler<CR>
For very quickly jumping between the current buffer, and the last buffer I have a mapping:
nnoremap <leader>dd <C-^>
because <C-^> is a bit awkward; <leader>dd could be anything that's very easy to type.
So most of the time I'm alternating between two files using the <C-^> mapping. When I need to jump to a less recently used buffer I double tap <space>, opening LustyJuggler, then double tap the appropriate home row key to jump to the buffer I want. If the buffer I want isn't in the ten most recently used, I open Ctrl-P, type enough characters from the file path of the file I want to make it the first choice, then hit enter.
You can make use of command-line completion:
:b <Tab>
:b js<Tab> completes with teh name of your JS file
set wildcharm=<C-z>
nnoremap <leader>b :b <C-z>
nnoremap <PageUp> :bnext<CR>
nnoremap <PageDown> :bprevious<CR>
nnoremap <leader>1 :b1<CR>
nnoremap <leader>2 :b2<CR>
nnoremap <leader>3 :b3<CR>
...
You can try listing and choosing in one move:
nnoremap gb :buffers<CR>:b<Space>
3<C-^> is equivalent to :b3<CR>
nnoremap & <C-^>
1&map <C-n> :bn<Cr>
map <C-p> :bp<Cr>
It probably helps that I've mapped caps-lock to ctrl so using ctrl is very convenient for me.
I have a friend who has a sweet setup with gvim that has a lot of tab and file management tools, so you might look into gvim, but I don't use it.
Thank you.
It's gotten to the point where I use a tiling window manager on my Linux distro with all controls Vim style. I have a Firefox add-on to give it Vim controls [1], and I use Vim for basic word processing. I can control almost every part of my OS, excluding Skype, purely through my keyboard with virtually no mouse involvement.
It's all very addicting once you get used to it.
I am definitely not a seasoned or prodigious programmer, but I find that most of my time is spent on reading, understanding, or planning code. By the time I begin coding, I will already have a strong idea of where I want to go, and I spend very little time actually typing or editing. The same is true for essay writing -- by the time I pick up the metaphorical pen, I have already finished most of the essay in my head, with only trivial details to hammer out.
Therefore, why not select the metaphorical pen which you find most enjoyable? For me, I choose Vim. And sometimes Sublime Text.
In the end, the best editor is the one you can leverage the most.
I agree though that there's no reason every programmer must try and learn vim; there plenty other editors out there, and if you're productive with one, there's no reason not to stick with it. Still, people want to try because they're curious, and if vim lives up to its reputation for them, well.. good for them I guess?
However, that's the only part of vim that I miss when not using it. I regularly use other editors that have vim keybindings. For example: Sublime Text is pleasant in Vintage mode and, and I regularly use IntelliJ IDEA with the IdeaVim plugin because of its advanced IDE features for ruby and JavaScript.
except that it can run in a terminal, which is nice on remote servers or in tmuxI agree, switching to Vim just because it is fashionable is a dumb move.
For the record, if ST had been available for Linux and Mac OSX at the time I was looking around, I'm 100% sure that it would have been my choice.
I think a person who is going to do anything with UNIX/Linux owes it to him or herself to learn either Vim or Emacs, if only for the occasional editing that needs to be done over a remote terminal connection. There are other editors, of course, but these are powerful ones.
I agree with you though. Basic vi usage for quick edits is part of UNIX/Linux literacy.
For example, there are a set of commands that move the cursor in different ways (beginning of line, end of line, first line, last line, line #x, next word, previous word, etc. (that's ^/$/gg/G/g#/w/b) ), and a set of commands that performs actions (copy, cut mostly (y/d)). The real magic is how the two sets interact.
I don't have to memorize the sequence of keys to delete a word; I know the key to cut (d), and the key to move a word forward (w). I press d, then w, and the word is gone! It's a whole world of editing possibilities.
My secret shame: since I use GUI vims almost exclusively, I've never developed the muscle memory for hjkl movement; I use the arrow keys. When I started out, I knew i, esc, and that, and I figured out the rest as I needed it.
There's got to be a better reason to use vim than this. I mean...the standard for every other editor is ctrl-shift-left arrow, then the delete key and the word is gone! Whoopee.
It works in most editors, even Microsoft notepad and this textarea I'm typing in right now. I use unfashionable, clumsy old eclipse most of the time and could probably list 100 important things it does that vim never could. Things that actually matter. Maybe I'm wrong, but I doubt vim can launch and debug and continuously deploy to Apache tomcat. That sort of thing.
I've been using vim for 10 years and I learn new things all the time.
At that point I wouldn't start looking things up all the time. Just set out to learn one new command or shortcut every two days, applying it in your daily use. Usually that's enough to get them in your mid-term muscle memory, so that you continue to use when you move on to the next command. The Vim pocket guide is great to choose what's up next.
I was already fairly adept at Vim when I applied this method to teach myself less frequently used Vim commands.
The only thing I recommend is Pathogen which keeps addons modular. From there only add things to the baseline as needed.
I tried switching to Ubuntu from OSX as many times as I tried abandoning Textmate for VIM.
The thing that made me finally keep using Linux was using a very stripped down version called "Arch Linux". This made me appreciate the basic fundamentals of the operating system, with no fluff [1].
It was rough around the edges at first but you learn how to deal with quickly.
I eventually switched to larger and easier-to-use Linux distros like Fedora/Debian. But whenever I run into problems with them, I have the experience to understand/fix it from working with Arch.
I now have no interest in going back to OSX and use VIM obsessively.
Many comedians will say this too: the only way to get motivated to be successful is with your back against the wall. Being partially comfortable makes you complacent.
That means incrementally building up your array of useful plugins and not installing them all at once. You want to be very selective about plugins in general anyway, and pay attention to which ones are the most useful to programmers who get a lot done, which will make you want to try them (I'm thinking NERDTree and Ctrl-P here).
Vim is a (surprise surprise) text editor, not a way of life. It's perfectly ok not knowing how to use vim and being put off by how awkward it feels. It's perfectly ok to use notepad++ or sublime text or whatever else you are comfortable with.
To my knowledge nobody gets paid to use vim instead of some other editor; money comes from lines of code. It does not matter that you use vim, it does not make you a smarter person or better programmer (I should know, I often use vim at my work place).
On the same note, it does not matter how cool you think you are when you manage to persuade git to do some complicated thing in a two liner command which could be achieved in svn or hg in two words, you are just being silly. Being proficient at vim/git when your job doesn't require it is like being able to rotate your left and right eyes simultaneuosly - one clockwise, the other counterclockwise. It's very funny/interesting, but utterly useless. Forcing yourself to learn vim for vim's sake or because you read on the internet how cool vim is and how 3l1t3 vim makes you is one of the things you'd be better off avoiding. Again, I should know.
Seriously, don't drink the Kool-Aid.
For instance, when working on a C++ code base, vim will never come close to the ease of use of Visual C++. It might be better at "delete 2 lines starting at line #256", but that's about it. This can be improved by plugins that most of the time will not do exactly what you'd like them to do, so you will have to "adjust your workflow" to work around that.
My original point was about using tools because it's cool or because the internet said so, and there's load of stories where people buy into how good vim is and then after a few months they still don't 'get it' so they are told they're doing it wrong (or just not smart enough). Ditto for git, lisp and other silver bullets.
If you ask me, if efficiency were important people would be using hg instead of git most of the time because most of the things you can do in git you can do easier/simpler in hg - at least for the most usual cases. After a short intro to hg people will keep using it happily ever after, whereas the git user will keep coming back to StackOverflow questions to find out how to hard reset to head after rebasing from origin and rewinding. Speaking of SO, this quote matches my thoughts exactly:
"It seems to me, that people using Mercurial are not so easily impressed. This is reflected in how each system do what Linus described as "the coolest merge EVER!". In Git you can merge with an unrelated repository by doing: git fetch <project-to-union-merge> GIT_INDEX_FILE=.git/tmp-index git-read-tree FETCH_HEAD GIT_INDEX_FILE=.git/tmp-index git-checkout-cache -a -u git-update-cache --add -- (GIT_INDEX_FILE=.git/tmp-index git-ls-files) cp .git/FETCH_HEAD .git/MERGE_HEAD git commit
Those commands look quite arcane to my eye. In Mercurial we do: hg pull --force <project-to-union-merge> hg merge hg commit"
I would like to read your insights related to efficiency.
I didn't know that I get free membership in the Church of Scientology base don my choice of text editor.
I also need to be able to navigate the code quickly but that might be part if your "tools to help me understand" remark.
It often takes me 20-30 minutes to edit a single line of code. Understanding why I need to change the program, what the effects of making that change are, determining which line of the code to edit, figuring out whether I need to edit or refactor, spending time in a REPL to test the proposed changes...
I just use the mouse.
But I take your point, and on my own projects, I stick with git, grunt, and rsync. Not a fan of SourceTree, and now that I know Vim, I can use git diff to good effect.
It's important being able to use vim, because sooner or later you'll edit some files on a remote server, but I don't understand the enthusiasm of so many people for it. Vimscript is horrible BTW.
I don't think I could've made it this far by diving in head first. Like it or not, I have to get work done, and when I couldn't get a motion to work right or didnt know the best way to do something, I could fall back on sublimes regular tools.
> I don't think I could've made it this far by diving in head first.
That's exactly my point! Take it easy and don't go hardcore from the first day. You'll get annoyed right away and you'll go back to Sublime Text in 10 mins.
https://chrome.google.com/webstore/detail/vimium/dbepggeogba...
Second mistake: using a distribution.
Third mistake: forking a distribution, itself built by amateurs, after only three months and advertizing it on the net.
Seriously, when did parents stop teaching the value of patience (among other values) to their kids?
You are the one in charge of your config, people, not some random guy on the internet.
By now, it did stick. What finally convinced me the most is that a lot of really smart people not only use it but have developed a fierce loyalty to this text editor.
imap jf <ESC>