Before this link, my .vimrc was 184 lines.
After reading this config it's 250 lines.
Thanks Steve for 66 lines of new awesome solutions.
Steve Losh's .vimrc
61–70 of 103 posts
Re: Steve Losh's .vimrc
#62That'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…
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).
Re: Steve Losh's .vimrc
#63That'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…
you can get around this by editing remote files with your vim over scp http://vim.wikia.com/wiki/Editing_remote_files_via_scp_in_vi...
Re: Steve Losh's .vimrc
#64inoremap # X#
This has been annoying me forever, but I never got around to fixing it. Not sure how the solution works, but it does!
Re: Steve Losh's .vimrc
#65Earlier quoted context omitted.
I dunno, I think the Python interface is adequate. Not great, but gets the job done. I write almost all my Vim scripts in Python.
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 mor…
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.
Re: Steve Losh's .vimrc
#66That'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 run wget -qO - bit.ly/newbox | sh or curl -Ls bit.ly/newbox | sh and am up and running. No sweat. I keep this stuff in Dropbox too, just in case.
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".
Re: Steve Losh's .vimrc
#67I didn't know this was possible: " Resize splits when the window is resized au VimResized * exe "normal! \ =" That's really handy. Also, this part made me smile: " Heresy inoremap I inoremap A
"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.
Re: Steve Losh's .vimrc
#68I didn't know this was possible: " Resize splits when the window is resized au VimResized * exe "normal! \ =" That's really handy. Also, this part made me smile: " Heresy inoremap I inoremap A
"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.
You could bind a key to :setlocal winfixwidth, and press that when you want a certain window to not be resized.
Or just not worry about it at all -- each person has their own way of working with Vim.
Re: Steve Losh's .vimrc
#69inoremap # X # This has been annoying me forever, but I never got around to fixing it. Not sure how the solution works, but it does!
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".
Re: Steve Losh's .vimrc
#70inoremap # X # This has been annoying me forever, but I never got around to fixing it. Not sure how the solution works, but it does!
It's (sort of) explained in :help smartindent.