These vimrc posts are not always very useful. Actually, it should be reminded that each line in vimrc may have bad side-effects. It may increase Vim instance loading time, and increase editing footprint, or slowdown processes like highlighting and scrolling.
Moreover, and probably worse, each specific configuration increases the distance between your daily Vim-fu and the one you'll have to use on another user or another machine. And these occasions have been, in my experience, those when great Vim-fu was the most critical (eg. trying to keep your hand on a dying server on a flooded connection, or showing off your skills on your boss's Mac during plane trip). All this holds for bashrc too. The closest to the default is the best, to some extent.
I take vimrc posts as good occasions to proofread mine and remove all unused stuff. I just commented out a very weird "set notagbsearch" which was probably killing my <ctrl>-].
Yeah, I've found that over the years my .vimrc gets shorter and shorter because I rewrite it from scratch with each new environment, taking with me only what I remember through everyday use. I'm down to 30 lines now, counting whitespace.
Well then you have to extend the argument to plugins as well, and certain plugins (SnipMate, AutoComplPop, Fugitive, etc.) can increase productivity by several orders of magnitude.
It's best to store your .vimrc + .vim/ folder on GitHub or a thumb-drive for easy restoration rather than crippling yourself with a limited configuration. Someone else mentioned Homesick (https://github.com/technicalpickles/homesick) which works really well.
I have the classic things about backspace, black background, statusbar, hlsearch, autocomplete, etc.
Then I have a few shortcuts on <Function keys>, because these cannot override other bindings. The most important is <F9> linked to pastetoggle.
I also have some specific settings for my current main language (Python).
I try to avoid rebinding normal keys because it can kill you when you get used to your tweaks and have to use another instance, but one thing I do is imap <ins> <Nop>, because I hate being suddenly thrown in replace mode.
Plugins I have grep.vim linked to <F3> and I'm currently trying NERD_commenter.vim on <F6>
I prefer a variant of that. You can specify more than one place (that is, first choice, second choice, etc.) with a comma-separated list. I do this:
" Vim 7.3, now with persistent undo
set undofile
set undodir=$HOME/.vim_undo,/tmp
That way, if I've remembered to create a .vim_undo folder, they go there (best option). Otherwise, /tmp. (You can do the same thing when specifying places for swap and backup files.)
As the comment suggests, the undo feature is only 7.3 or better.
Insert single characters: Press 's' in normal mode and the next character you type will be inserted at the cursor and put you back in normal. Press 'S' (Capital S or shift+s) and the character will be inserted after the cursor like 'a' append. This is also repeatable, so you can insert a character and then do '5.' to insert it 5 times, still leaving you in normal mode afterwards. Being repeatable is the reasoning I read for it being a function. I picked this up from the Vim wikia site awhile ago.
" Insert single char (repeatable)
function! RepeatChar(char, count)
return repeat(a:char, a:count)
endfunction
nnoremap <silent> s :<C-U>exec "normal i".RepeatChar(nr2char(getchar()), v:count1)<CR>
nnoremap <silent> S :<C-U>exec "normal a".RepeatChar(nr2char(getchar()), v:count1)<CR>
Press 'F5' to run the file you're editing, assuming it has a shebang.
" Run current file if it has a shebang
function! <SID>CallInterpreter()
if match(getline(1), '^\#!') == 0
let l:interpreter = getline(1)[2:]
exec ("!".l:interpreter." %:p")
else
echohl ErrorMsg | echo "Err: No shebang present in file, canceling execution" | echohl None
endif
endfun
map <F5> :call <SID>CallInterpreter()<CR>
I don't actually use this one a lot, but it can be handy. F10 to switch between the line numbering modes, in Vim versions that have relative line numbering (>= 7.3)
" Toggle line numbering modes
" Default to relativenumber in newer vim, otherwise regular numbering
if v:version >= 703
set relativenumber
let s:relativenumber = 0
function! <SID>ToggleRelativeNumber()
if s:relativenumber == 0
set number
let s:relativenumber = 1
elseif s:relativenumber == 1
set relativenumber
let s:relativenumber = 2
else
set norelativenumber
let s:relativenumber = 0
endif
endfunction
map <silent><F10> :call <SID>ToggleRelativeNumber()<CR>
else
set number
endif
This is an ugly hack I came up with to layout my windows how I like them. I have NERDTree and Taglist in a horizontally split window to the left and MiniBufExplorer across the top of the screen. See http://yfrog.com/h7sg7fp
autocmd VimEnter * call<SID>LayoutWindows()
function! s:LayoutWindows()
execute 'NERDTree'
let nerdtree_buffer = bufnr(t:NERDTreeBufName)
execute 'wincmd q'
execute 'Tlist'
execute 'wincmd h'
execute 'split'
execute 'b' . nerdtree_buffer
let mbe_window = bufwinnr("-MiniBufExplorer-")
if mbe_window != -1
execute mbe_window . "wincmd w"
execute 'wincmd K'
endif
execute 'resize +20'
execute 'wincmd l'
endfunction
That does it! I've read about both these extensions before, but tomorrow morning I'm taking the time to set them up on my machines. The setup looks like exactly what I've been wanting. Split windows only go so far, and still doesn't let me easily have more than a few buffers visible at once.
It's a shame that SO doesn't allow these types of questions anymore. They are very useful for beginners who want to know how experienced users actually use the tool.
The fact that they cannot be answered objectively doesn't make them less useful, and contrary to what is stated in the FAQ, the question and answers model is perfectly suited to this type of question.
Not really: "What's in your .vimrc?" is a question.
Don't get me started on the idea to have separate "sites" for every topic. It creates a lot of noise, confuses beginners and serves no practical purposes that tags can't fulfil.
StackOverflow, and it's family of sites, aim to answer questions that can have a single "most correct" answer. While "what's in your .vimrc"-style questions are undoubtedly helpful, they are beyond the scope of SO et al.
I work with multiple files a lot, so I'm always navigating between split screens and across buffers.
" Split windows/multiple files
" use <Ctrl>+s to split the current window
nmap <C-S> <C-W>s
" use <Ctrl>+j/<Ctrl>+k to move up/down through split windows
nmap <C-J> <C-W>j
nmap <C-K> <C-W>k
" use <Ctrl>+-/<Ctrl>+= to maximise/equalise the size of split windows
nmap <C--> <C-W>_
nmap <C-=> <C-W>=
" use <Ctrl>+h/<Ctrl>+l to move back/forth through files:
nmap <C-L> :next<CR>
nmap <C-H> :prev<CR>
generally speaking, this .vimrc is most core config file that had a most use for me, been messing around with it before, and finally i use janus carl and huda https://github.com/carlhuda/janus (had to thanks to them) for their distro of the .vimrc configuration, it include just all what i need for my macvim, it has a good plugins and configurations to where i can start of developments.
for others that don't want to mess around with vimrc configs (although its fun)just give it a shot and hopefully, and will happifly accept an contribution
make sure I'm scrolling visual lines, not real lines
noremap j gj
noremap k gk
ctrl+l/h for changing tabs
noremap <C-l> gt
noremap <C-h> gT
Search improvements:
set incsearch
set hlsearch
Best theme ever (very objective of course):
let g:inkpot_black_background = 1
colors inkpot
Making sure tmp files are stored in only one location, not all around the system:
if ! isdirectory(expand('~/vimtmp'))
call mkdir(expand('~/vimtmp'))
endif
if isdirectory(expand('~/vimtmp'))
set directory=~/vimtmp
else
set directory=.,/var/tmp,/tmp
endif
Now you can run `vim foo bar baz` and then when open just type `\ta` and it will open them cleanly in three different tabs. Why they renamed a command "tab ball" I will never know.
" Automagically save files when focus is lost
autocmd BufLeave,FocusLost silent! wall
" Highlight whitespace at the end of a line
highlight ExtraWhitespace ctermbg=Black guibg=Black
match ExtraWhitespace /\s\+$/
autocmd BufWinEnter * match ExtraWhitespace /\s\+$/
autocmd InsertEnter * match ExtraWhitespace /\s\+\%#\@<!$/
autocmd InsertLeave * match ExtraWhitespace /\s\+$/
autocmd BufWinLeave * call clearmatches()
" Disable man key
nnoremap K <nop>
While the flexibility and portability of Vim is quite attractive, I doubt I could really retrain myself to use the modal interface. Are there packages/scripts/whatever that would allow one to use Vim in the way that one would use a more "normal" text editor?
Gvim in insert mode is essentially a "normal" editor, I.e. You can use it like ms notepad. But that would defeat the whole purpose. It takes memorizing about a dozen key bindings to be proficient with basic editing, and then you're off to the races. You'll have no problem.
I'm not a vim scripter, but I'd be willing to bet you could make a (very very simple) script that would dump you back into input mode after a single command. That, or use a gui vim and ignore the whole command-mode thing (probably augmented with the before-mentioned script) and use buttons.
It's worth mentioning that Cream is completely Vim underneath, however, by default it uses the Common User Access interface for user input like most modern editors.
It is also possible to enable traditional Vim input using expert mode, CUA is retained in insert mode making it very easy for anyone not familiar with Vim to get started and transition.
I go with whatever the default is. I've logged on to hundreds of *nix machines in just the past few years, and it's completely not worth the effort to try and maintain a concurrent configuration.
Why does it matter if there's no standard location? Do you use the ; command that often in vim anyway that this would be an issue if it were mapped to \?
Ymmv but it unfortunately matters for me. I switch between my work PC and personal Macbook daily. The different positions for \ drive me crazy, but as least it's rarely used on Macs due to sane file paths. Using a moving key in Vim is a bad idea.
Ctrl-[, too. But for some reason it's not as smooth for me. This idea of mapping semicolon came from a command layout rethink experiment I originally did on emacs. Always been meaning to reconstruct that more fully some day. Vim doesn't make it possible to define new first-class modes, so it will probably have to be a from-scratch editor (if I ever get around to it).
I have mapped Caps Lock to switch between input and command mode. I use F10 as a "placeholder" to avoid triggering an actual changing of caps lock mode.
Moreover, and probably worse, each specific configuration increases the distance between your daily Vim-fu and the one you'll have to use on another user or another machine. And these occasions have been, in my experience, those when great Vim-fu was the most critical (eg. trying to keep your hand on a dying server on a flooded connection, or showing off your skills on your boss's Mac during plane trip). All this holds for bashrc too. The closest to the default is the best, to some extent.
I take vimrc posts as good occasions to proofread mine and remove all unused stuff. I just commented out a very weird "set notagbsearch" which was probably killing my <ctrl>-].