Is there a Vim equivalent of Emacs's C-h k followed by the key combo, which basically says, "Tell me what the official command name is for this keystroke?"
I don't know of anything quite like that but the help can be searched by key, though only for the default key combinations, e.g. ":h i^a" would show the docs for the ctrl-a command in insert mode.
Note though that vim really doesn't have commands the same way as emacs does. That's why you generally see assigning one key combination to another instead of some "command name."
You can bind a key to a command too. However, mapping to keys allows you to create your own. To give you a crude example, you could map a key to go down 5 times (5j). A real example would be more complicated for some specific task -- jump to other window, maxmimize it, go down to 5th line or some bookmark, etc.
"C-w =" equalizes the size of splits. That works fine if you already had them near-equal, but I frequently shrink or maximize split windows, and I don't want them equalizing every time the window resizes.
Having paired with many people who have loaded Emacs keybindings into Vim, this made me laugh.
But serious talk:
Unless someone has loaded Emacs keybindings, shouldn't <C-a> be used to increment a number (even a hexadecimal one)? How is that heresy? Not having <C-a> makes several macros difficult.
I think that having all of this in one file is too crazy. I suggest putting some of the stuff in the appropriate files in ftplugins, etc in your ~/.vim directory.
Some of this definitely belongs in separate files.
The problem is that most of these are things I came up with when, during the middle of coding, I thought "oh, this would be really nice". So I just switched to my vimrc, added it, and got back to working, instead of thinking about where to put it, creating new files, etc.
Every so often I'll go through and clean it up. I just haven't gotten around to it for a long time since it works perfectly fine as is.
Actually I'm planning on splicing it into MakeGreen, so instead of getting a green bar when my tests pass I get Nyan Cat flying across my window. Maybe over Thanksgiving weekend I'll get around to it.
Edit: Also, if anyone can show me how to draw an ASCII-art Nyan Cat in one line of text that would be awesome. Nothing I tried looked recognizable.
That's one thing that worries me about using vim full-time: if I become reliant on a .vimrc or a set of plugins to use vim effectively, but I'm on a computer that doesn't have my .vimrc on it, I'm doomed.
I feel exactly the opposite. The previous editors that I used required configuration through a menu system. I wouldn't have known how to take that with me elsewhere.
With Vim, all my configuration is in files, which can be backed up. I have them in a dotfiles repo on Github. As I make tweaks, I regularly pull and push from my various computers and they are always up to date. If I'm on a computer that doesn't have my .vimrc, I'm just a `git pull` away from having it. (Same goes for zsh config, etc.)
The most likely time for me not to have my .vimrc is when sshing into a server, in which case I can use stock vim just fine. If my main editor were a GUI, I wouldn't have it available at all, so I think Vim has a leg up in that, too.
By the way, if you're ever confused about what behavior is native and what comes from your config, use the `-u "NONE"` option to run vanilla vim (or macvim or gvim).
I do the same thing. But I also have customized branches to work with my config. I will usually make new commits on the computer-specific branch and then cherry pick the commits to master and then rebase the computer-specific branch on top of master. This can get a little repetitive and result in my computer-specific branches getting very out of date so I wrote a bash script called git-update to streamline this process for me. Here's the code:
This is why people place them on github or bitbucket. So it is very easy to clone the repo locally and then use the .vimrc. It is something you only have to do once per machine.
This is what I do as well. To make thinks simpler, I use this script to automatically create the symlinks (if they are not already existant). If you put it in your `.zshrc`, you can run the command `dropbox-update-dotfiles` to make or update the symlinks. Not that this makes use of `zsh` extensions, so it requires adaptation to use with bash.
dropbox-update-dotfiles () {
src="$HOME/Dropbox/dotfiles"
dst="$HOME"
if [[ ! -d "$src" ]]; then
print "Directory $src not found."
fi
for f in "$src"/*~*(.swp|~|.pyc)(D); do
if [[ -h "$dst/${f:t}" ]]; then
# exists as symlink
elif [[ -e "$dst/${f:t}" ]]; then
print "WARNING: ${f:t} exists, but is not a symlink."
else
ln -sv "$f" "$dst"
fi
done
}
I link my dot files as well as Documents, Pictures, Music, and Desktop directories that are also normally controlled by OSX. Having those shared across multiple computers is awesome. Sit down at a computer, and it's there.
I also have my zsh files checked in to bitbucket (https://bitbucket.org/tednaleid/shared-zshrc/) so even if the computer doesn't have dropbox (like many of the linux servers I have access to), as long as it has mercurial, I can clone the repo and be ready to go.
Does that computer have a network connection? Just store your plugins and settings in a git repo (a good idea anyway) and pull them down on whatever machine you're using.
cd
hg clone http://bitbucket.org/sjl/dotfiles .dotfiles
ln -s `pwd`/.dotfiles/vim/.vimrc ~/.vimrc
cd -
My full Vim config is now installed, plugins included thanks to Mercurial's subrepos.
But really, I don't find myself editing files directly on servers all that often. And when I do I usually prefer bcvi anyway, because I can use MacVim instead of Vim through a terminal (which I hate because of all the shadowed keys).
Rather than type in the symbolic link commands, I just have a config script that I run (also checked into version control) that will move the old .vim directory, .bashrc, and other files out of the way, and install links to the version controlled file instead. Easy.
I've basically memorized my .vimrc and .gvimrc files from retyping them over and over again, but then I take the approach of using the standard configuration when possible and only customizing the minimum required, so it's not as bad as it sounds.
The power of VIM as an effective and consistent text editor is far more important to me than the power of VIM as a highly configurable editor.
This is why I stick pretty close to stock vim - I use it on too many remote systems to worry about keeping my environment consistent. I could automate something, and maybe when our sysadmin finishes integrating puppet into our servers I can use that, but in the meantime, my .vimrc is just syntax highlighting and tab settings.
Even in new computer without net connection vanilla vim is good enough for editing. When sit in an alien computer with vanilla vim. At first I put these lines in .vimrc
set nocp
set hidden
set ts=2
set sw=2
set autoindent
set incsearch
filetype on
filetype plugin on
map <C-J> <C-W>j
map <C-K> <C-W>k
map <C-l> <C-W>l
map <C-h> <C-W>h
For buffer management, combination of :ls, :b and :b# does the job well enough, compiling command-t plugin isn't necessary :). For listing of files there is :sexplore . For code browsing there is plain old ctags. There you go, almost 90% of environment created. Other things like surround or snipets support would be better. But I don't use them most of the time :).
echo set ts=3 > ~/.vimrc
echo "Toggle search highlighting on and off with F5 >> ~/.vimrc
echo map "<F5> : set hls\!<bar>set hsl?<CR>" >> ~/.vimrc
Everything else is gravy for me. While an extended rc is handy and I often store one where I can get to it, if I'm just editing a couple of files, vanilla + the tab size I want and a shortcut to highlighting search terms gets me going. YMMV
I tried to get into emacs, but I kept coming back to vim. Probably because the first editor I really used was a version of 'ed' back when I played MUDs.
That's a huge amount of trust you've placed in bit.ly, and in insecure http. You might at least consider typing out https://bit.ly/newbox so that you only have to trust bit.ly. Better yet, memorize the URL that bit.ly links to.
Also, why do you symlink your dotfiles into your cloned git repo, rather than just checking out the git repo as ~? Personally, I just move the .git directory from the clone to ~, and then "git checkout -f".
I'm lazy and don't want to type out the github URL, but you're right I should place the redirection under my control and use HTTPS. Honestly though I cannot think of a single reason why anyone would want to hijack my script. I don't do anything very interesting that would make my machine a lucrative target for that sort of malicious activity. I'm a very small fish in a massive pond.
Also due to laziness I don't want to add a bunch of stuff to .gitignore, or add * and then add exceptions. I like having the symlinks.
Just watch out that you don't get a 404 one day and end up piping a whole lot of error screen HTML into your shell, it could have wildly unpredictable results.
On foreign machines I'm rarely doing anything complicated enough where not having my .vimrc is noticeable. If I'm going to be spending a lot of time working on something, then it isn't a problem to either use my local machine or sshfs the remote server and work on it from my local editor.
I try and keep my .vimrc limited to configuration and enhancement and not change how the core works. Things like rebinding builtin actions will never be seen in my .vimrc.
I've had that concern as well but have not found it to be a problem in practice. For one thing, it's not hard to go back to default vim if you're on a different system. For another, it's usually not that hard to copy your .vimrc over if you're going to stay awhile.
Really? You are doomed because you don't have some extra configuration niceties? Basic vim editing is not enough?
Then I have to ask: what exactly are you doing in that other computer?
If it's just some temporary sysadmin stuff and the like, then you surely can get by with the basic vim functionality.
Now, If you're gonna be using that other computer for a longer period, then why not just add your .vimrc there? With github, bitbucket, dropbox et al you can have your configuration pushed to the other computer in seconds.
I also find that with everybody having laptops these days, the need to use some "other computer" is much less frequent.
vimscript really is an abomination. vim users of the world unite! and create a proper macro language for your editor. and no: running an external python/ruby/brainfuck process does not count.
Using Python and other runtimes is often kind of slow - it's not a huge deal but if you have a lot of this stuff in your config, then vim might start up only like 8 times faster than Eclipse.
The other thing is that the Vim API you use in these other languages is pretty much Vimscript anyway.
For me, Vimscript is basically a normal imperative language in the general neighborhood of perl and shell... I agree it is more awkward to write than Python, particularly with escaping. But it's a decent DSL for configuring text editors, and Python isn't as much.
The two advantages of using Python for me are being able to use utilities I've already written, and the comprehensive standard library.
For example, I wrote a macro to split long Python function calls into multiple lines, and I could access a parsing function that I already wrote, along with Python's own compile() to detect when I've parsed a complete expression (yes, this one is Python-specific).
I also wrote a macro to submit the current file to a private pastebin, and AFAIK you can't make web requests with Vimscript.
Here's a commented version of my .vimrc, which is modeled after Steve's, albeit nowhere near as comprehensive. (Looks like I lost it's fixed width in the paste? Sorry!)
For me it's a lot quicker to reference comments than the :help entry for each option. Thought it might help others who are creating/modifying their .vimrc.
And of course, thanks Steve for continuing to share your stuff. I'm in love with Vim, and a lot of that's thanks to you.
I'm sure I've seen this in vim, but I can't find it now. Isn't there a statusline config item that shows any pending command prefix chars you've typed?
I highly recommend putting your vim configuration on github or similar, you don't have to worry about losing your config and it gets easier for everyone to learn the new tricks
There are a bunch of different methods for folding (indentation, manual markers, custom syntax-based folding, etc), and which one you want usually depends on the file type.
I have a bunch of autocommands for different files that set the foldmethod appropriately. For example:
augroup ft_vim
au!
au FileType vim setlocal foldmethod=marker foldmarker={{{,}}}
augroup END
augroup ft_js
au!
au FileType javascript setlocal foldmethod=marker foldmarker={,}
augroup END
This makes Vim fold using markers for Vim and Javascript files. The Vim markers are the usual {{{ and }}}, but Javascript has it's own "built-in" markers we can take advantage of, so it uses { and }.
This is probably b/c you're using 'smartindent' or 'cindent' all the time. Don't. The former is deprecated by the latter and they're only for C-like syntax--hence why # belongs in column 0. If you want filetype-specific indenting, you just need "filetype indent on".
Ugh. Be careful with that, since actually giving a /g has the effect of toggling the behaviour all together.
From :help 'gdefault':-
:help 'gdefault'
'gdefault' 'gd' boolean (default off)
global
{not in Vi}
When on, the ":substitute" flag 'g' is default on. This means that
all matches in a line are substituted instead of one. When a 'g' flag
is given to a ":substitute" command, this will toggle the substitution
of all or one match. See |complex-change|.
command 'gdefault' on 'gdefault' off ~
:s/// subst. all subst. one
:s///g subst. one subst. all
:s///gg subst. all subst. one
While not quite documented under ":help :s_flags", two 'g' flags cancel each other out. This also applies to 'gdefault'.
Also, be aware that this may break a huge amount of scripts out there, should you decide to use it as some (hard to debug) issues are caused because of it.
I've had this set for a while now and haven't noticed any scripts breaking. It's far more common for scripts to break because I'm remapped something and they used 'nmap' instead of 'nnoremap' or 'normal' instead of 'normal!'.
Whenever a script breaks, I bite the bullet and fix it, fork it on Github, switch my dotfiles repo to use my fork and send a pull request. If they merge my fix I switch my dotfiles repo back.
It's a pain in the ass, but I like to think that it helps other Vim users a little bit.
But my laptop has 8 gigabytes of RAM, a solid state hard drive, and four processor cores.
I can run Minecraft at the highest settings while accidentally leaving a Linux VM running in the background. Loading a 1.5k vimrc file is barely a blip on the processor graph.
vimrc affects startup time, but like any program it isn't the lines but the work done which will make it slow or fast. How slowly does your computer read a 1000-line text file? vim is fast, setting some parameters in vimrc doesn't change that. Avoiding configuration that will make your life easier out of fears about performance is premature optimization.
If you have a ton of autocmds for frequent events, things can slow down. I also find that things can get slow when LOTS of calls are made to a language other than Vimscript.
But fundamentally, run Eclipse and Netbeans and gedit and emacs - vim should compare favorably even with a ton of config.
If you want to actually profile your startup time, try this on a recent version of vim:
vim --startuptime=vim.log
I don't think that the author wrote his 1200 lines of .vimrc in one sit. More likely it's years of accumulated 1-2 line additions and removals.
My vimrc has slowly accumulated, I add 1 or 2 new keybinds every now and then and I might remove them later if I notice they don't suit my workflow. Most of my changed keybindings are related to making Vim usable with my native keyboard layout (finnish/swedish).
Also per-language additions accumulate over time. The author seems to have put all settings for all file types in the same file.
Learning standard Vi gets you a long way, but sometimes adding or changing a keybind will make things work more fluently.
My point was, time better spent is coding, not dicking around (and relying) on .vimrc.
We often forgot about the essence of things such as typing the actual code or words, and focus on tools. Better investment is learning how to properly type than having countless little helpers which are nothing more than debt.
Increasing complexity in all areas of life really is troublesome.
I think you're thinking about it backwards. It's usually not thinking "what could I tweak today" that results in adding something to .vimrc. It's "I keep doing this a lot / this feel uncomfortable, maybe there's an easier way" that results in changes. And if you take time to actually implement it, that's a good indication it was worth the tweak.
Let's say you work with splits a lot. Sure you could press ctrl+w all the time, but it's a bit annoying. Rebinding doesn't take much time, but makes it (in the presented example) actually simpler. So did it waste time? A minute or so. Does it make life easier? A little bit. Did the "coding time" suffer? Who cares about a minute or so ;)
There is no dichotomous distinction between coding and using vim to automate tasks. The latter is part of the former - no different from using q or @ or .
I think it is all about productivity and if he feels or thinks he is more productive with these additions then it is really good for him. I don't think anyone should use plain vim because it's 'way it should be done'.
Sometimes we don't realize things. I was using Vim before. I loved it, tweaking it all the time, thinking it helped me to achieve various things faster etc.
When I switched to nvi I realized how wrong I was. My .nexrc contains less than ten lines. There is no syntax highlighting. I was also forced to learn real vi properly. When you do such things amazing things happen.
Anyone who knows who sjl is could have easily found his vimrc through his website. According to the bitbucket history, the file has been hosted there since at least 2009.
Did I say it wasn't useful? Maybe you missed my point.
I could post a link to a perldoc page for some builtin function, and that would be useful, and it's probably been around for awhile, and probably nobody knows who wrote it. Would you defend that too?
http://stevelosh.com/projects/