This is helpful, particularly the resources listed, but I would advise against using someone else's config starting out. Continually editing my own .vimrc for the first few months was a big part of learning. If you use someone else's dotfiles right from the start, there's a good chance you'll end up believing some behaviour is default when it really isn't, and that's going to mess you up.
I agree with this very strongly. The first time I tried to learn VIM, I installed janus [1], and ended up with this monstrous, complicated system with a million plugins that I didn't understand. The mouse sort of worked, but not the way I expected it to.
I'm now sort-of trying to learn VIM again. My vimrc has about 10-15 lines in it, and I know what each one does. I have a color scheme installed, but no other plugins.
How I boosted my Vim [2] has been helpful to me in adding things to my vimrc, because Vincent Driessen is, as always, clear-minded and erudite in his description of what things do, and has good taste on a basic setup that will make sense to the modern developer. Again though, I haven't blindly pasted in all his stuff—instead, when I feel some friction with my Vim settings, I head to that article and see if there's a tweak he's listed that I can use.
Agreed. There's a great post Vim: revisited with a minimal .vimrc file that I used after having to start over learning Vim because of using someone else's .vimrc I didn't need or fully understand: http://mislav.uniqpath.com/2011/12/vim-revisited/
Well, when I started using Emacs, I copied a lot of snippets of code which I didn't understand, and it didn't hamper my learning process. Quite the contrary, it sped it up because I was able to override some annoying behaviors before learning how to do it.
That was a huge mistake for me when first learning vim. If you start with someone else's .vimrc, you will run into a lot more "FML, what is going on" experiences that you should.
So has anyone ever been a die-hard vim user, been absolutely seduced by Emacs and the wealth of things that go with it (IRC? Org mode? Holy crap!), tried to use it, and been completely turned off by the abundance of control keys?
This describes me. I really, really want to like Emacs and learn to use it, but coming from vim, such heavy use of the meta keys just feels wrong.
I'm in the same boat. I learned vim and when I went to university all they use is emacs. I've tried time and time again but as you say it somehow feels wrong. Why do I have to dislocate my finger just to do a commnad? Vim feels much less in the way when doing stuff.
With that said I'm trying to use emacs org mode to keep myself organized, which works great! But I would never trade it with vim as my code editor, not in a million years. Sorry.
I tried several times and failed several times. What won me over in the end was the need to do some project management and the discovery of Org-Mode. Those checkboxed lists and tables are pure magic.
So what I really needed was a use case to make me use it properly. Once you see the awesome power of Org-Mode and try to imagine what else you could do, you see the potential of Emacs.
After that, it is the all-too-well-known cycle of "This is rather tedious", "there has to be a better way to do this" and finally discovering yet another new keyboard shortcut.
Also, get into the habit of using isearch (C-s, C-r) as a replacement for many of the Vim search commands (fFtT/? etc.). This makes Emacs a lot more manageable if you are used to Vim motions.
But really, I don't feel the need to use only Emacs or Vim. I switch freely between them depending on the task at hand.
That said, I did and do have trouble getting over the fact that Emacs seems to be unable to handle mousewheel-scrolling properly and has rather poor support for code folding. Not deal breakers, those, but come on, this is 2012!
Yes, that's me. It took me three tries in as many years to make the switch. So don't give up.
It wasn't the various alternate modes that enticed me so much as a more consistent buffer model for file-find, greps, and compiles. And I'm very happy not to have that constant "am I in insert or command mode?" problem. The control keys are now second nature.
I'm a die-hard vim user, who's used vim for many years.
I tried emacs with viper and vimpulse recently, and found that while they did make emacs a lot less painful, they were a far cry from making a long-time vim user comfortable in emacs.
The biggest problem is that in order to configure emacs and bind functions to keys you have to invest a lot of time in reading documentation and finding out about emacs.
If you have that sort of time to invest, great. But I didn't, especially since I already know vim very well and feel completely comfortable using and configuring it. Switching to emacs just didn't seem worth the time investment in my particular case.
I have heard that evil was a better vim emulation mode for emacs, and I've been meaning to give it a try, but haven't gotten around to it yet -- and I'm still skeptical of it addressing my main concern, which is that to really use emacs effectively (even in vim emulation mode) you'd have to invest a lot of time in learning the emacsy parts.
There is one other major issue that none of emacs' vim emulation modes address, which is the thousands of vim plugins available on www.vim.org. You might, in the best case, get all the standard vim keybindings for emacs, but you'd still be forced to use emacs scripts and plugins, instead of the vim scripts and plugins you like and are used to. Learning and transitioning to those is yet another big time sink right there.
One of the main reasons that I switched to emacs was to use SLIME to interface with Common Lisp. But SLIME is a huge program, and learning to use it and configure viper/vimpulse to bind keyboard shortcuts to its functions requires spending a lot of time learning about and understanding SLIME. It's just so much simpler to one of the less feature-rich vim plugins to develop code in CL. Yes, you'd miss out on some great SLIME features, but you would also not have to spend a ton of time learning SLIME and configuring viper/vimpulse to work with it.
I've found the path of least resistance is to not change the default keybindings of the various emacs packages. Use the vi bindings for text manipulation and when you need to invoke a package function it's back to the ctr/meta chords. It's the text manipulation that's burned into my brain so as long as vimpulse takes care of that I'm mostly happy.
It's true though that if you're heavily invested in vim plugins there's fair time sink in getting up to speed on the emacs equivalents. Everything's a tradeoff.
Learning emacs has been something I've been pushing back for too long. Currently I'm a Vim user but I'm deeply unsatisfied with the way it integrates to my other tools like debuggers and build systems. Emacs is far superior when it comes to this, even the best of Vim plugins are not as good.
But I like the Vi input model so much that I want to be able to use it in Emacs. I've understood that "evil" is the preferred Emacs-Vi-input layer these days (instead of viper or other alternatives). I'm going to use Emacs 24.
I'm a bit of a stuck record on this issue but my opinion is that the first thing that someone new to Emacs should learn is how to change key bindings. The rough guide line being that Vim key bindings should never be changed but Emacs key bindings always.
Still, unless you start using a vi emulation mode or keychords.el you will always be stuck with the meta keys. For me this was no problem since vi's modal approach to editing always rubbed me the wrong way. (I used Vim for almost 10 years before making the switch to Emacs.)
i'm playing with emacs + evil-mode for the better haskell support. so far it looks pretty good, and the thought of hacking up some elisp to fill in missing bits is a lot less offputting than hacking in vimscript.
I used to use Vim, and then I got a job after college working with .NET (this was in 2003). Since then I've used Visual Studio as my primary IDE. Its features (or that of Eclipse) seem to (pardon the pun) eclipse the crap out of Vim. The contextual information you get in VS by hovering your mouse on any variable, the built-in debugging, etc. Studio isn't a just text editor, it actually understands the semantics of your programming language, it helps you write better code faster.
And that is why VisualStudio is considered an IDE rather than an editor. As with the rest of the *nix toolkit, the philosophy with Vi(m) is to do one simple thing (editing) and do it really really well, for better or worse.
I fundamentally agree that doing less and doing it well is a virtue in software, but people don't "just" "edit text." When I edit text I'm either writing a document/web page (where I need to format it in addition to editing the text), or writing code (where I need to debug and test it). I still use Vim when I ssh into my firm's Linux server and I'm so glad that it works--so well--over a remote session. But for actually writing a program, I'm happy to have a proper IDE.
For Java, NetBeans + vim plugin does just that. Major win. Same editor (almost, plain old vi) in impoverished production environments, full vim under cygwin for quick patches, and the same keystrokes in my IDE with all the other goodies for long term projects.
I have no idea why I keep using Vim. These past few days I've been trying to switch to Eclipse for coding, as it has all the bells and whistles, but as soon as I need to open another file in the editor, I find myself switching to the command line and opening it in Vim, wondering why the hell I did that with Eclipse open.
I think it just comes down to speed, in the end. I can switch to Vim and open the file in the time it takes Eclipse to go from ctrl+T to the "find file" dialog. Code completion, refactoring, autoimports, etc are great, but I manage fine without them.
Am I the only person who thinks it's absolutely insane how much time people spend learning to use an editor?
Am I really supposed to believe that my time is better spent learning an editor than it is spent getting better at programming?
I honestly feel that learning these editors has more to do with gaining status than it does self-improvement.
Why should I have to spend hours consciously learning an /editor/. It's /just/ an editor, the interface should be good enough that I can just walk in and use it productively from the start.
For the record, I used vim for the first 2 years of my degree, now I use gedit. It certainly lacks some functionality, but it's generally good enough and feels like much less of a burden to carry: I'm free to focus on actual work.
I'm not sure the many hours I spend 10+ years ago learning vim are really worth it, when compared to the amount of time I saved during editing. However:
1. I had a consistent editing experience for those 10+ years, and expect to have it for decades to come - vim is everywhere, and it works the same everywhere (well at least if you stay away from things that may not be time-proof, like plugins that rely on Python support). It gives me peace of mind - it's a stable factor amongst things that tend to change every 6 months, usually for no good reason.
2. I have a comfortable editing experience, one that is so ingrained that it has become transparent (meaning, I don't notice it any more, like a good pair of shoes that are so comfortable you don't notice wearing them). When I use Visual Studio on a machine with no Viemu installed, there is this continuous nagging feeling that the editing is so sub-optimal. Again I don't know if the time I spend learning vim is objectively justified when compared to the annoyances of the editing in 'plain' editors, but it certainly made for a great quality of life improvement.
I got to go everywhere I wanted to go with my old Citroen, and it was (quite a bit) cheaper than the BMW I drive now, but I still very much like the BMW's improved comfort and joy of driving. Is it objectively a net for me to drive a BMW? I suspect not, the objective marginal value I get out of it over the Citroen is low, but it's worth the money (where for the sake of comparison with vim, money = time) to me.
To me, comfort is also the main reason to use vim.
Not having to think about where the buttons are that I have to press to accomplish something, not having to leave the home row... that's comfortable.
While I'm sure I'm faster doing the same tasks with vim than I would be using a regular editor, the comfort of not having to consciously think about what I have to do is clearly the bigger one.
Personally, I have spent a lot of time customizing and mastering Vim. But I agree with you that mastering a powerful editor is not a sufficient condition to be a good programmer. That realization occurred to me after I found that a few programmers that I respect very much have very primitive editing skills (which was very difficult for me to swallow at first).
it's not even a necessary condition. it has, however, made my life a lot more comfortable and pleasant, given the amount of time i spend entering text into a document and then editing it in various ways. there are things that i can do almost without thinking about them in vim that would involve effort, tedium or both if done any other way.
The speed increase on paragraph editing capabilities is really attracting versus pointing your mouse to do everything. I'm gonna give it a shot, thanks.
It took me two weeks before I finally grew comfortable with vim, so don't get discouraged. Start off by treating it as a regular text editor. Use the arrow keys to move around, use control (windows) or option (mac) + arrow keys to quickly move between words, etc. Slowly introduce a few vim shortcuts at a time. It was also helpful for me to write the commands on a whiteboard or a post it and have it on my monitor as reference.
Yeah, having them written down off to the side helped me finally learn vim. There are many vim cheat sheets out there via a quick google that I wish I would have used starting out.
I love Vim and have been a happy MacVim user for a while now. But I just started using Vico and I am really liking it. It's definitely missing a lot of the features that Vim has accrued over time, but the native UI and polish of Vico has me using it full time now.
Hm, I used GVim/MacVim for a few years and was very comfortable with it, but the more I was doing heavy editing on remote machines, or even Linux VMs on my local machines, the more GVim felt like a crutch.
I now will only use terminal vim and I can't imagine going back. It's very nice being able to have the same editing experience as long as I can SSH in. And sshfs etc are not solutions due to the need for shell integration and the problem of latency on write.
An added benefit is that all of my heavy applications live in the console, making it much easier to keep things organized, especially when I am using screen.
As someone who loves vim I'm both surprised and curious that he mentions using vim to write .NET code
While I love vim, I can't imagine using it to write anything significant in .NET - the lack of auto completion and an integrated debugger is a deal killer for me. I'd love to hear the author, or anyone else, elaborate on what kind of setup they use for writing .NET code in vim (note that I already use the vim plugin for VS, I assume this isn't what the author is referring to though)
I am stuck with windows and cygwin. Is there a way to run vim without the weird bugs? I run rxvt and still see a lot of weirdness with vim, I really only use it for quick edits. I would love to put in the time to learn it better, but I don't want to suffer through weirdness on top of the learning curve.
Every week there's some post like this, or "why I switched back and forth between Vim and Textmate 17 times", and, frankly, I just don't see the merit in it. Are you trying to get other people to use the editor you like?
"Please don't submit comments complaining that a submission is inappropriate for the site. If you think something is spam or offtopic, flag it by going to its page and clicking on the "flag" link. (Not all users will see this; there is a karma threshold.) If you flag something, please don't also comment that you did."
