The cleanest vimrc you'll ever see(yanpritzker.com)
yanpritzker.com
The cleanest vimrc you'll ever see
http://yanpritzker.com/2012/01/20/the-cleanest-vimrc-youve-ever-seen/
9 comments
I couldn't disagree more. The point of being able to configure tools in the first place is to be able to make them suit the user and enhance the users experience and hence increase productivity. 'Fiddling' around with ones tools and discussing configurations with people is a fantastic way to discover new shortcuts or usage patterns than can make using them a lot more pleasant. Of course people looking to procrastinate can spend hours editing their dotfiles but that's no reason to suggest it's 'net harmful' to talk about them.
This doesn't deserve downvotes. Its a legitimate, and smart, way of approaching vi for a lot of reasons. In my opinion, it should be <10 lines
I'll agree with you though I like to have at least a few in there like autoindent, various tabstop and search related settings, or syntax highlighting.
I'll agree with you though I like to have at least a few in there like autoindent, various tabstop and search related settings, or syntax highlighting.
I often hear that one should not customize their Vim settings because when they have to use another machine they will be at a disadvantage but I must say that I really cannot understand this attitude.
My .vimrc is has a good deal of custom stuff that I rely on during day to day coding, but on occasion when I have to use, say, busybox's 'vi' (which by the way isn't even quite POSIX) I very rarely have any trouble at all. Certainly not enough trouble to negate the productivity gain I see with my .vimrc.
My .vimrc is has a good deal of custom stuff that I rely on during day to day coding, but on occasion when I have to use, say, busybox's 'vi' (which by the way isn't even quite POSIX) I very rarely have any trouble at all. Certainly not enough trouble to negate the productivity gain I see with my .vimrc.
alias vim=pico
this is a good approach to vi, as well :P
this is a good approach to vi, as well :P
alias vim=pico
alias pico=nano
alias nano=emacsIt even represents the spirit of emacs!
;)
;)
alias emacs=vim
I was hoping to find your reply on the top.
As so many I started my 'vim-experience' by adding a lot of plugins, rc-settings, themes etc.
Finally I almost used as much time configuring, backing up my dot files and tweaking as I used on real actual programming.
I understand some settings are crucial (or may be nice), but I would recommend you use more time thinking and implementing your application.
I firmly believe that the KISS-principle (Keep it simple, stupid) is as important to IDE/Editors as it is writing software code.
As so many I started my 'vim-experience' by adding a lot of plugins, rc-settings, themes etc.
Finally I almost used as much time configuring, backing up my dot files and tweaking as I used on real actual programming.
I understand some settings are crucial (or may be nice), but I would recommend you use more time thinking and implementing your application.
I firmly believe that the KISS-principle (Keep it simple, stupid) is as important to IDE/Editors as it is writing software code.
Spending a few hours up front improving the tools I use saves me hours every day. A small investment in getting your tools right more than pays off. I am insanely productive in my workplace while saving myself from RSI by using smart vim configs.
To me, it really doesn't matter if you maintain your plugin settings in your .vimrc or in separate files, as long as it's well annotated and organized the way you like it.
Plus, all I have to do is track my .vimrc in my dotfiles repo and let Vundle manage my plugins for me.
Plus, all I have to do is track my .vimrc in my dotfiles repo and let Vundle manage my plugins for me.
I followed the modular init file approach at first, but keeping track of dependencies between different modules was a chore. Having all of my initialization code in a single file greatly simplifies maintenance: I could instantly tell what code runs before or after a certain line and I could easily navigate among sections of code and fold them based on headings.
Nowadays, my emacs init file is 239 kB. Is it messy? Yes, in some places, for customizations I don't care that much, it is, because each section I rely on constantly gets constantly refactored.
Modularization helps when you are going to share code among different projects, but your init file is a single project, what does splitting it buys you? Only increased complexity. Of course, as soon as functions get refactored and made more general and independent, they go into a module of their own.
Nowadays, my emacs init file is 239 kB. Is it messy? Yes, in some places, for customizations I don't care that much, it is, because each section I rely on constantly gets constantly refactored.
Modularization helps when you are going to share code among different projects, but your init file is a single project, what does splitting it buys you? Only increased complexity. Of course, as soon as functions get refactored and made more general and independent, they go into a module of their own.
Remap caps-lock to escape
Ugh, why? Remapping caps-lock to Ctrl makes more sense to me. The Escape key is still in the upper-left, and banging somewhere in that vicinity usually hits it. Also Ctrl-C equals Escape in vim, so you still have quick access to it from the home row if you want.
Ugh, why? Remapping caps-lock to Ctrl makes more sense to me. The Escape key is still in the upper-left, and banging somewhere in that vicinity usually hits it. Also Ctrl-C equals Escape in vim, so you still have quick access to it from the home row if you want.
I remapped Capslock to:
"Ctrl if it's held down and pressed with another key, Escape if it's pressed and released on its own."
It works really nicely once you get used to it.
EDIT:
To do that I first mapped Capslock to Ctrl using the normal Apple Keyboard prefs, then used KeyRemap4MacBook and checked this setting: http://i.imgur.com/99cNs.png
http://pqrs.org/macosx/keyremap4macbook/
"Ctrl if it's held down and pressed with another key, Escape if it's pressed and released on its own."
It works really nicely once you get used to it.
EDIT:
To do that I first mapped Capslock to Ctrl using the normal Apple Keyboard prefs, then used KeyRemap4MacBook and checked this setting: http://i.imgur.com/99cNs.png
http://pqrs.org/macosx/keyremap4macbook/
I remapped Caps Lock to Escape too and it interestingly one of the best hacks I ever did. On my keyboard at least, Esc is far away from the home row, and the smallest button on my keyboard (1x1.6 cm^2). Caps Lock is the fourth largest button (1.8x3.2 cm^2) and is only a small distance to the left. I can easily reach Ctrl with my pinky, but not Esc.
It's also useful outside of Vim, in almost any application Esc means "Cancel the current operation". The only disadvantage I see is that I'm constantly toggling Caps Lock on other PC's.
It's also useful outside of Vim, in almost any application Esc means "Cancel the current operation". The only disadvantage I see is that I'm constantly toggling Caps Lock on other PC's.
I have "jj" mapped to esc, caps-lock remapped to Ctrl.
jj only an issue if you are tying things like jj.Reddick or jj abrams :)
jj only an issue if you are tying things like jj.Reddick or jj abrams :)
The reason is capslock is on the home row, and control is not. I use a Kinesis Advantage keyboard, so ctrl is also in a good spot (thumb), but for most people, less stress would be to use the homerow key rather than bend their pinky to hit ctrl. It's a minor thing but it adds up.
If you use escape with vim you're actually "doing it wrong" in the sense that vim was not designed for your keyboard. On older keyboards escape was where the Tab key is now. There's no reason to abuse your wrists with repetitive motions going up to the escape key.
If you use escape with vim you're actually "doing it wrong" in the sense that vim was not designed for your keyboard. On older keyboards escape was where the Tab key is now. There's no reason to abuse your wrists with repetitive motions going up to the escape key.
Eh. I already have two ctrl keys, and use escape far more often then either of them. Ctrl-z is the only common thing I do with control, and I don't need that to be easily done from the home row.
I remapped space to colon (so I can enter commands without shifting for colon). :)
well nnoremap ; : is a good way to do that and keep space open for other things unless you use ; for something more useful.
I'd recommend not mapping over ; It's very useful. It repeats your last f or F command. I probably use it a dozen times a day.
If you do map something on top of it, consider moving it elsewhere.
If you do map something on top of it, consider moving it elsewhere.
That's actually quite useful... I was working off a modified vimrc that had this remap on it and got used to it. Maybe leader f to redo? Though I haven't checked if that is taken by something else. Thanks for the tip.
But not the best: https://github.com/Diablo-D3/dot_vim
Edit: Woah, that guy needs to learn how to use Vundle and not embed third party files in his git repo, and let Vundle fetch it for him (look at mine for example)
Edit: Woah, that guy needs to learn how to use Vundle and not embed third party files in his git repo, and let Vundle fetch it for him (look at mine for example)
I think git submodules + pathogen is a perfectly legit way to fetch/install/manage vim plugins.
Except he didnt use git submodules, he embedded them right in his git repo, which means he can never keep up to date.
Also, Vundle is pathogen inspired, its designed to be an easier way of doing the same thing, complete with automated updating for gitted stuff.
Also, Vundle is pathogen inspired, its designed to be an easier way of doing the same thing, complete with automated updating for gitted stuff.
I know what vundle is.
Pretty sure we can't be looking at the same repo, because as far as I can tell, these are git submodules https://img.skitch.com/20120120-jx8g6cpj8amdagh6dtfbyjtjbp.j... (screenshot)
Re: Keeping up to date
Pretty sure we can't be looking at the same repo, because as far as I can tell, these are git submodules https://img.skitch.com/20120120-jx8g6cpj8amdagh6dtfbyjtjbp.j... (screenshot)
Re: Keeping up to date
git submodule foreach git pull origin master --recurse-submodulesyep, they are proper git submodules, and this way you can specifically control which of them you want to update, and when.
FWIW, I used vundle for quite a while and went back to pathogen because vim's load time was much faster. Perhaps they have improved that.
vim --startuptime time.txtWell, if we're getting out the tape measure, this is my current inspiration:
https://github.com/mutewinter/dot_vim
https://github.com/mutewinter/dot_vim
I have my vimrc on github as well. It gets the job done for me. Keep in mind I'm far more of a sysadmin than a programmer.
https://github.com/daniellockard/vimrc
https://github.com/daniellockard/vimrc
I've been meaning to clean up my vimrc. I think I may finally do it. Vundle seems like it would be nicer to use, though.
This is an example of poor refactoring. Also, "cleanest" is not better.
[deleted]
I mean, it's cool and all that you love your tools, but I suspect these sorts of blog posts are net harmful when you consider the number of people who will read it and take it as an opportunity to fiddle around with settings in a program as a way of further putting off making something meaningful.