I did not know there was a "great" debate between Textmate and Vim. I would expect the camps to be rather far apart. It would be nice if the "new" version of Textmate would come out. It seems to be floundering.
I think it's just a hot topic currently in the Ruby community because there is so much blogging and memes take hold faster than in other developer communities.
That said, I am a ruby developer on OS X, and I have been using TextMate as my primary editor even though I cut my teeth on basic vi usage 15 years ago. The fact that TextMate 2 is suffering serious second-system syndrome is undoubtedly a big part of why Vim is getting so much mindshare.
TextMate is an amazing editor, and in my (limited) experience, certainly one of the few in the last 2 decades to even attempt to challenge emacs/vim on their own turf (ie. lightweight powerful editors). But ultimately I think a one-developer closed source model will never be able to create a third truly great editor.
The main factors driving me towards vim are maturity and general editing optimality.
Maturity because vim has been around and is open source, so millions of wrinkles have been ironed out: very few crashing bugs, good performance on large files, handles edge cases well and has settings for probably anything you'd ever need, etc.
Optimality because vi attempts to allow editing with the fewest number of keystrokes. Becoming fluent in vi means that for any type of text editing you can make any desired change in a near optimal number of keystrokes. It's a pretty safe bet that no one will ever come up with a more optimal editor for such a wide range of tasks. Sure IDEs have a high local maxima, but they fall off quickly as you jump to files that fall outside known semantics. TextMate gives you a middle ground for writing quick snippets and commands, but I'm starting to question the long term value of that versus the benefits of universal availability and just taking some time to find good plugins for various language-specific development.
I definitely felt somewhat pushed by the mythical creature that TextMate 2 is. This isn't to say I have any outstanding critical issues with TextMate as it is, more that I feel like I've plateaued with it, but I know there's a faster way of doing things by watching Vim masters at work.
Katz's post was the catalyst to pushing me to actually go and try it; he seemed like he was a similar mindset to me, and his success spurred me on.
Defaults: Agreed, though those of us who have been on vim for a long time obviously have a .vimrc we carry around. It'd be nice to have a better set of defaults.
Plugins: Vimballs already solve this problem largely.
Automatically in insert mode: Oh gosh no. The only case where you'd want to start in insert mode, I'd guess, is a new file. If you're opening an existing file, you're not going to start wanting to type at the beginning of it. Generally the first command in a file is a search or jump to line.
The author mentioned that he wanted a plugin that can quickly comment a line. There's more than a few ways to do this manually in vim that is quick. For example, to comment a block:
^<ctrl-v><n>jI# <ctrl-[>
where <n> is the number of lines to comment. You can also easily write a command in your vimrc to comment the current line in one keystroke.
I second this, the people in #vim are awesome and usually very quick to answer your questions. It's also one of the friendliest channels I've been in, for what it's worth.
I think it might be telling that the first I've heard of Vimballs is your comment, so I won't say much more about that :) It seems only Supertab Continued with it's odd ":%so" install thingy was a Vimball, but the author never called it that on his Vim.org/scripts page.
Automatically in insert mode is what I expected to be the most divisive comment, and it proved so! Maybe this would be solved by my distribution suggestion: new users get Vim in insert mode, seasoned vets get Vim in normal mode on start-up. There isn't one setting that will please everyone, although I do have a suspicion that the normal mode at start-up turns off more people than might be expected.
For the comment command deal, I found similar blog posts along that line. Again, I think it's the sort of command that isn't obvious to new users, and you need to be jiving with the Tao of Vim before it makes sense (I only have a half handle on it myself). I just wanted a keyboard command, like Textmate's Cmd+/ . NERD Commenter's key command is ,/, which makes me happy, and it works across multiple file types. My hope is that when I get better at Vim, I'll be able to come up with such commands myself, but I don't expect that sort of proficiency for months, if not years. I'm perhaps a slow learner ;)
A few people have mentioned vimballs as a plugin solution. There are (at least) two other potential solutions for plugin handling: Pathogen and Vimana. Pathogen is what the blog author is actually using already, but he didn't realize it initially. He refers to a .vim repo on Github that "does some magic where [it] puts each plugin in its own directory under /~.vim/bundles/." What he describes here is based on Tim Pope's Pathogen: basically a plugin to manage all other plugins. I've been using Pathogen for a bit now, and it's excellent. Another solution is Cornelius Lin's Vimana, which I've heard very good things about, but I haven't tried. Some links below.
It's funny that out of nowhere, all these ruby developers jump on the band wagon after reading a few blog posts. Then they immediately complain about it being so terrible.
The original version of vi was written in 1976.
The first version of vim was released in 1991.
The 19/34 year old defaults of vim/vi aren't good enough for the hipster rubyists. However they seemed to be just fine for the hundreds or even thousands of systems developers and hackers who developed the foundation for the systems the take for granted. Rubyists are the loudest, most complaining, annoying group of egotistical developers to have ever existed. Vim is an editor, not emacs, not Textmate. There is no reason to use it or blog about it, or utter it's name if you don't think it fit's your work flow. Really, 99% of people don't care about your opinion on vim at all.
Also a small observation:
Every Textmate user I have ever met (who all also happen to be rubyists) depends too much on "bundles" and snippet features.
> The 19/34 year old defaults of vim/vi aren't good enough for the hipster rubyists. However they seemed to be just fine for the hundreds or even thousands of systems developers and hackers who developed the foundation for the systems the take for granted.
Yes, because as we know these hackers have empty .vimrc files. No sirree, just the defaults thanks!
However, as you are point out, every body has a .exrc/.vimrc In my useless opinion the current defaults are as general as they can be. I believe they are currently set so that both 20 year veterans and beginners can use any instance of vim if they happen to be without their favorite .vimrc config.
I do. The only time I set a .vimrc is on Debian-derived distros where they don't set nocompatible or syntax on.
vi has good defaults. If I used emacs, I'd have to drag around my config everywhere to set usable keybindings. With vi and vim I can just use the defaults everywhere.
I hope I didn't give the impression I think Vim is terrible. If I did, I wouldn't have said at the beginning that I'd moved to it completely. I think it's just suffered under the weight of it's age, where defaults, audiences and expectations were different. What I found interesting was that the things that turned me off were really easily solved; there's nothing wrong with the core of Vim at all. It's just window-dressing issues that someone with more skills than I would be able to solve relatively easily.
I wouldn't call myself a Rubyist (I like Scala more), but I'd prefer the hipster tag to loser ;)
I actually don't think depending on bundles and snippet features is bad at all. I think that indicates the flexibility of TextMate from first boot, and it means users are getting to the power the editor is providing, rather than skimming across the top. But when I watch a Vim pro though, it's light years faster than how quickly I can move around. As the other commenter mentioned, they do have highly customized .vimrc's and such to get to that place though.
Just FYI my comment wasn't really a personal attack on you or your post. I was talking more in general, I've seen several within the last week through many different channels.
Vim with sane defaults was create a few years ago, it's called cream http://cream.sourceforge.net It didn't really take off, at least as far as I know.
The problem here is that no matter how much you like vim, when you argue against the most important paradigm (defaulting to normal mode) that makes vim so powerful, the people who understand and appreciate this feature will assume that you don't like vim itself. And then you'll get people saying that you're utterly clueless.
Vim is a tool. Let me say that again. VIM IS A TOOL. It's purpose in life is not to be easy to use or to garner the biggest user base. It's purpose in life is to make text editing as efficient as possible. That means that you default to normal mode. Period. If you don't live in normal mode, then you just don't grok vi(m).
I'm not sure what's different about our use cases, but I find the vim defaults to be quite reasonable. I have a .vimrc file, but pretty much consists of syntax highlighting and tabstop settings. And I differ from the mainstream here anyway.
Ya I think it's a bit of the dunning-kruger effect at work. He's been using the editor for 2 weeks and can see what it needs more than people who have been using it for years.
I think you've misread my post, which is probably my fault. I don't see "what it needs" I tried to state "what made my life hard when I started using it, and what it seems would make that curve easier". I think they are different statements, and I hope that comes out of the text.
I am absolutely not saying that Vim is broken or that Vim is bad for the people that love Vim, I'm saying that Vim doesn't seem to meet expectations of people coming to it fresh. I think the idea of having different distros would help alleviate some of the pain. It looks like Cream has made a good go of it, but sadly no Mac version :(
I'm just surprised they're all stampeding to vim. Emacs seems like a better fit for the rails world. I'm certainly not getting pried away from my /usr/bin/emacs.
Funny timing, I just started my annual "gonna try to switch from TextMate to vim" last night.
It seems like every time I do this the amount of time I use vim gets longer and longer (went from a few days to a week to a few weeks to a month). Every time I learn more and more things that make me edge toward switching to vim full-time. I've got pretty much all the basics down, and I think I might stick to it this time.
The things that are helping me out the most this time are: increasing my system key repeat rate, lowering the repeat delay, and buying PeepOpen http://peepcode.com/products/peepopen
For the next step, I highly recommend Vimperator plugin for Firefox. It uses Vim keybindings and really gets your fingers used to using the letters for commands instead of ctrl+keys.
So I know this won't be popular, but I've got to say it.
I'm baffled at these text editor debates.
It's almost like developers think that code-input is a significant part of their job. It's not. It's just some accidental complexity that goes with the territory. Speeding up your text-wrangling ability won't do anything to help you be a better/faster developer.
I use vim all the time (as well as a bunch of others) and yes of course it was an unnecessary pain-in-the-ass to learn. It's all mindless rote learning that doesn't prove anyone's smarter than anyone else either. My theory is that people won't admit this because they're already invested and on the other side of the steep learning curve.
The bottom line is that there's no editor that will make you a better programmer. If you're worried about quick input, you're probably banging out boilerplate and not working at the right level of abstraction.
Totally disagree. The kind of shoe you wear is conceptually orthogonal to your job of walking from one place to another. Practically, however, your choice will drastically impact your comfort, walking range, and possibly even overall health.
So pick an editor (or set of editors) that fits, is comfortable, and lets you walk, run, jog, and sprint.
Sure it wont make you a code whisperer, but once you find an editor that works with your way of thought, you find some crazy cool stuff does happen. For me, it has become as if my editor is directly connected to my brain. If i want to go to a function definition, it just happens. If I want to search, i find myself a the target without every thinking "now i need to do a search". When refactoring I can move chunks of code around, and refit everything to the new pattern without any thought of the text level changes. This is brought by knowing a good tool well combined with knowing the code base and language well. However, without the tool I couldn't be nearly as effective.
I think you've created a straw man by this point. Nobody's saying a text editor will turn you into a Nietzschean Übermensch. However, even if it isn't that radical, good tools that make the incidental details go smoothly can still make a big difference.
Oh, I absolutely agree it's accidental complexity and won't make you a better developer, but we can always optimize, no?
Is there a really good reason to choose Python over Ruby? Usually not, but some people do take a lot of time thinking about such things :)
I personally find the ecosystem of software development interesting, I enjoy debates about minuscule language features or text editors or design patterns. I am not really sure why; maybe I think it exposes the variety of the discipline, and I think it might make you a more well-rounded programmer if you take in that wider view. It's hard to put my finger on and verbalize.
When I was in graduate school, I took up pool. I played every day for five years, at least one hour a day and often as many as three or four. In my second year, friends gave me a pool cue. Most pool halls provide cues, of course, and most of those cues are fine. (Other than truly warped ones which are rare and easy to spot, it's mostly a matter of finding one in a size and weight that suits you.)
The nicer cue didn't make me a better player in any direct sense. However, it was (and is) a joy to handle. It has obvious craftsmanship: the weight and balance is just so; it swings easily in my hands. I look forward to using it, and I care for it very well. So, indirectly, it probably contributed to the improvement of my game.
tl;dr A well-made tool can bring its own reward. Tools you want to work with and care for encourage good habits and practice. These things are not nothing. Programming is not merely a mental activity of juggling abstractions.
Everybody uses editors differently, and perhaps for your approach and workflow it doesn't make a significant difference. In my experience using vim has made my work day more enjoyable than other editors did, and while I don't think it directly impacts my code, I sometimes think that the increased happiness probably does have a positive impact on the quality of my work.
And even if it doesn't, the increased happiness is a virtue unto itself. The point is, find the tools that make you happy and use them. They don't have to be the same ones other people are using.
I recently converted from various other graphical IDE's (Visual Studio and Eclipse) to start using exclusively Vim to develop with, and I'm loving it.
I don't think it really needs to be made more accessible, but what would have been AWESOME would be to have known about vim-tutor. I only just found out about it after I've spent a few weeks working in Vim, and have largely passed the time when vim-tutor would have helped. It REALLY should be on the main vim screen, not in the help.
Maybe I'm weird in that I have an inherent distrust the help in open source apps. Most of the times, they seem to be archaic, and targeted at the very advanced users (see man pages).
Thankfully, I've passed the initial stumbling-around period, and now know that the help is actually written in a very readable format. Maybe all that needs to happen is for that to be better communicated.
A sidenote, but for people who are following the Vim 7.3 betas, 7.3e (which is meant to be the last beta - this is last call for problems) was out yesterday. I've been using 7.3 a little, and persistent undo (undo history between editing sessions) is very nice.
46 comments
[ 1049 ms ] story [ 1415 ms ] threadThat said, I am a ruby developer on OS X, and I have been using TextMate as my primary editor even though I cut my teeth on basic vi usage 15 years ago. The fact that TextMate 2 is suffering serious second-system syndrome is undoubtedly a big part of why Vim is getting so much mindshare.
TextMate is an amazing editor, and in my (limited) experience, certainly one of the few in the last 2 decades to even attempt to challenge emacs/vim on their own turf (ie. lightweight powerful editors). But ultimately I think a one-developer closed source model will never be able to create a third truly great editor.
The main factors driving me towards vim are maturity and general editing optimality.
Maturity because vim has been around and is open source, so millions of wrinkles have been ironed out: very few crashing bugs, good performance on large files, handles edge cases well and has settings for probably anything you'd ever need, etc.
Optimality because vi attempts to allow editing with the fewest number of keystrokes. Becoming fluent in vi means that for any type of text editing you can make any desired change in a near optimal number of keystrokes. It's a pretty safe bet that no one will ever come up with a more optimal editor for such a wide range of tasks. Sure IDEs have a high local maxima, but they fall off quickly as you jump to files that fall outside known semantics. TextMate gives you a middle ground for writing quick snippets and commands, but I'm starting to question the long term value of that versus the benefits of universal availability and just taking some time to find good plugins for various language-specific development.
Katz's post was the catalyst to pushing me to actually go and try it; he seemed like he was a similar mindset to me, and his success spurred me on.
Actually, the doc says that you need to do the following:
With macVim, I found that simply double clicking the .vba in finder does everything needed.Plugins: Vimballs already solve this problem largely.
Automatically in insert mode: Oh gosh no. The only case where you'd want to start in insert mode, I'd guess, is a new file. If you're opening an existing file, you're not going to start wanting to type at the beginning of it. Generally the first command in a file is a search or jump to line.
The author mentioned that he wanted a plugin that can quickly comment a line. There's more than a few ways to do this manually in vim that is quick. For example, to comment a block:
^<ctrl-v><n>jI# <ctrl-[>
where <n> is the number of lines to comment. You can also easily write a command in your vimrc to comment the current line in one keystroke.
I need like a vim tip a day or something to show me more of these tricks.
Ctrl-v is used to enter (column) visual mode, and ctrl-[ is a shortcut for the esc key.
Automatically in insert mode is what I expected to be the most divisive comment, and it proved so! Maybe this would be solved by my distribution suggestion: new users get Vim in insert mode, seasoned vets get Vim in normal mode on start-up. There isn't one setting that will please everyone, although I do have a suspicion that the normal mode at start-up turns off more people than might be expected.
For the comment command deal, I found similar blog posts along that line. Again, I think it's the sort of command that isn't obvious to new users, and you need to be jiving with the Tao of Vim before it makes sense (I only have a half handle on it myself). I just wanted a keyboard command, like Textmate's Cmd+/ . NERD Commenter's key command is ,/, which makes me happy, and it works across multiple file types. My hope is that when I get better at Vim, I'll be able to come up with such commands myself, but I don't expect that sort of proficiency for months, if not years. I'm perhaps a slow learner ;)
http://github.com/tpope/vim-pathogen
http://tammersaleh.com/posts/the-modern-vim-config-with-path...
http://ithaca.arpinum.org/2010/06/28/vim-updates.html
http://github.com/c9s/Vimana
tpugin (on demand path manipulation): http://github.com/tomtom/vimtlib/blob/master/macros/tplugin....
scriptmanager: http://github.com/MarcWeber/vim-addon-manager
It's funny that out of nowhere, all these ruby developers jump on the band wagon after reading a few blog posts. Then they immediately complain about it being so terrible.
The original version of vi was written in 1976. The first version of vim was released in 1991.
The 19/34 year old defaults of vim/vi aren't good enough for the hipster rubyists. However they seemed to be just fine for the hundreds or even thousands of systems developers and hackers who developed the foundation for the systems the take for granted. Rubyists are the loudest, most complaining, annoying group of egotistical developers to have ever existed. Vim is an editor, not emacs, not Textmate. There is no reason to use it or blog about it, or utter it's name if you don't think it fit's your work flow. Really, 99% of people don't care about your opinion on vim at all.
Also a small observation: Every Textmate user I have ever met (who all also happen to be rubyists) depends too much on "bundles" and snippet features.
Yes, because as we know these hackers have empty .vimrc files. No sirree, just the defaults thanks!
However, as you are point out, every body has a .exrc/.vimrc In my useless opinion the current defaults are as general as they can be. I believe they are currently set so that both 20 year veterans and beginners can use any instance of vim if they happen to be without their favorite .vimrc config.
vi has good defaults. If I used emacs, I'd have to drag around my config everywhere to set usable keybindings. With vi and vim I can just use the defaults everywhere.
I wouldn't call myself a Rubyist (I like Scala more), but I'd prefer the hipster tag to loser ;)
I actually don't think depending on bundles and snippet features is bad at all. I think that indicates the flexibility of TextMate from first boot, and it means users are getting to the power the editor is providing, rather than skimming across the top. But when I watch a Vim pro though, it's light years faster than how quickly I can move around. As the other commenter mentioned, they do have highly customized .vimrc's and such to get to that place though.
Vim with sane defaults was create a few years ago, it's called cream http://cream.sourceforge.net It didn't really take off, at least as far as I know.
Vim is a tool. Let me say that again. VIM IS A TOOL. It's purpose in life is not to be easy to use or to garner the biggest user base. It's purpose in life is to make text editing as efficient as possible. That means that you default to normal mode. Period. If you don't live in normal mode, then you just don't grok vi(m).
I'm not sure what's different about our use cases, but I find the vim defaults to be quite reasonable. I have a .vimrc file, but pretty much consists of syntax highlighting and tabstop settings. And I differ from the mainstream here anyway.
I honestly feel like a old man on my porch, screaming "Get of my editor lawn!".
I am absolutely not saying that Vim is broken or that Vim is bad for the people that love Vim, I'm saying that Vim doesn't seem to meet expectations of people coming to it fresh. I think the idea of having different distros would help alleviate some of the pain. It looks like Cream has made a good go of it, but sadly no Mac version :(
It seems like every time I do this the amount of time I use vim gets longer and longer (went from a few days to a week to a few weeks to a month). Every time I learn more and more things that make me edge toward switching to vim full-time. I've got pretty much all the basics down, and I think I might stick to it this time.
The things that are helping me out the most this time are: increasing my system key repeat rate, lowering the repeat delay, and buying PeepOpen http://peepcode.com/products/peepopen
I'm baffled at these text editor debates.
It's almost like developers think that code-input is a significant part of their job. It's not. It's just some accidental complexity that goes with the territory. Speeding up your text-wrangling ability won't do anything to help you be a better/faster developer.
I use vim all the time (as well as a bunch of others) and yes of course it was an unnecessary pain-in-the-ass to learn. It's all mindless rote learning that doesn't prove anyone's smarter than anyone else either. My theory is that people won't admit this because they're already invested and on the other side of the steep learning curve.
The bottom line is that there's no editor that will make you a better programmer. If you're worried about quick input, you're probably banging out boilerplate and not working at the right level of abstraction.
So pick an editor (or set of editors) that fits, is comfortable, and lets you walk, run, jog, and sprint.
Your choice of text editor is just a micro-optimization. As much as I'd like, there isn't one that will turn me into the code-whisperer.
Is there a really good reason to choose Python over Ruby? Usually not, but some people do take a lot of time thinking about such things :)
I personally find the ecosystem of software development interesting, I enjoy debates about minuscule language features or text editors or design patterns. I am not really sure why; maybe I think it exposes the variety of the discipline, and I think it might make you a more well-rounded programmer if you take in that wider view. It's hard to put my finger on and verbalize.
The nicer cue didn't make me a better player in any direct sense. However, it was (and is) a joy to handle. It has obvious craftsmanship: the weight and balance is just so; it swings easily in my hands. I look forward to using it, and I care for it very well. So, indirectly, it probably contributed to the improvement of my game.
tl;dr A well-made tool can bring its own reward. Tools you want to work with and care for encourage good habits and practice. These things are not nothing. Programming is not merely a mental activity of juggling abstractions.
And even if it doesn't, the increased happiness is a virtue unto itself. The point is, find the tools that make you happy and use them. They don't have to be the same ones other people are using.
I don't think it really needs to be made more accessible, but what would have been AWESOME would be to have known about vim-tutor. I only just found out about it after I've spent a few weeks working in Vim, and have largely passed the time when vim-tutor would have helped. It REALLY should be on the main vim screen, not in the help.
Maybe I'm weird in that I have an inherent distrust the help in open source apps. Most of the times, they seem to be archaic, and targeted at the very advanced users (see man pages).
Thankfully, I've passed the initial stumbling-around period, and now know that the help is actually written in a very readable format. Maybe all that needs to happen is for that to be better communicated.
-- Ayjay on Fedang
Announcement and how to get it: http://xrl.us/bhvizi
I guess he wrote a shell script at ~/bin/q that killed Vim processes?