Why are vi[m] efficient code editors?
9 comments
Where are your data proving that vim offers 'no real gains' (or as you intimated in another thread, that it is actually counterproductive to use vim)?
I'm puzzled at how you can ask about 'gains' and at the same time, discourage comparing vim to anything else. Isn't your question about relative advantage?
If you disqualify things like startup time, portability, and plugins you are now talking about a meaningless comparison. Those are real features vim has and you are just trying to exclude them in an effort to tilt toward your predetermined conclusion that vim is bad.
I'm puzzled at how you can ask about 'gains' and at the same time, discourage comparing vim to anything else. Isn't your question about relative advantage?
If you disqualify things like startup time, portability, and plugins you are now talking about a meaningless comparison. Those are real features vim has and you are just trying to exclude them in an effort to tilt toward your predetermined conclusion that vim is bad.
The reason I use vim is precisely what you have access to. OS X has vim, Linux has vim, and there are all different versions and ports of it. If not vim, then at least vi. Do I need all my plugins to be sufficient? No. Is it nice to have my customized look, yes.
In the end my productivity at any work station is not defined by which program I use, but how well I know the code. I try to not let my environment affect my workflow as much. If I sit down at any computer with some way of SSH, or a terminal emulator then I will be able to code my heart out.
One last thing I notice with vim, everything seems to be a keystroke away. Searching and moving the the next line, adding to the end of the current line, indenting the line, moving to the beginning of the line. It's so quick. Certainly every other editor out there has realized this and has the same features, but they are gummed up by the fact that they are always in insert mode. For me it is faster because I don't use left shift or control. Some people prefer emacs style bindings for everything they do. They don't mind throwing the left pinky down and hitting shift or ctrl. I find it so unusual so I find vim bindings much easier to become accustomed too.
Does that provide any help?
In the end my productivity at any work station is not defined by which program I use, but how well I know the code. I try to not let my environment affect my workflow as much. If I sit down at any computer with some way of SSH, or a terminal emulator then I will be able to code my heart out.
One last thing I notice with vim, everything seems to be a keystroke away. Searching and moving the the next line, adding to the end of the current line, indenting the line, moving to the beginning of the line. It's so quick. Certainly every other editor out there has realized this and has the same features, but they are gummed up by the fact that they are always in insert mode. For me it is faster because I don't use left shift or control. Some people prefer emacs style bindings for everything they do. They don't mind throwing the left pinky down and hitting shift or ctrl. I find it so unusual so I find vim bindings much easier to become accustomed too.
Does that provide any help?
> Does that provide any help?
Not a recipe, but yes.
Can you explain this comment a bit further: "they are gummed up by the fact that they are always in insert mode"
How is being in insert mode problematic? A scenario or two might be useful.
I use vim with git all the time and can't say I enjoy having to go in and out of insert mode every time I touch it.
Not a recipe, but yes.
Can you explain this comment a bit further: "they are gummed up by the fact that they are always in insert mode"
How is being in insert mode problematic? A scenario or two might be useful.
I use vim with git all the time and can't say I enjoy having to go in and out of insert mode every time I touch it.
Staying in insert mode all the time is not ideal because you aren't usually inserting text all the time.
Since a large part of editing a text file is manipulating the text that is already there, most of what makes vim powerful hangs out in the other modes. In "normal" mode, you can type out two or three keys and quickly communicate not only where you want the cursor to begin editing, but also how much text you want to replace. There are a endless number of these short little sentences you can communicate to vim quickly about where and what you intend to edit.
This kind of complexity can be intimidating to a new vim user, especially if you go looking for a vim cheatsheet and find that keyboard layout that shows what each key does in each mode. YOU DON'T NEED TO KNOW THAT. At least, not yet. Just install the vimtutor package, repeat it every once in a while, and internalize the basics. Learn the things that are useful to you. Most vim questions are wildly googlable. Type in ":help", and read the description of how the command and navigation works. Then use it whenever you can't remember how every other command works.
Since a large part of editing a text file is manipulating the text that is already there, most of what makes vim powerful hangs out in the other modes. In "normal" mode, you can type out two or three keys and quickly communicate not only where you want the cursor to begin editing, but also how much text you want to replace. There are a endless number of these short little sentences you can communicate to vim quickly about where and what you intend to edit.
This kind of complexity can be intimidating to a new vim user, especially if you go looking for a vim cheatsheet and find that keyboard layout that shows what each key does in each mode. YOU DON'T NEED TO KNOW THAT. At least, not yet. Just install the vimtutor package, repeat it every once in a while, and internalize the basics. Learn the things that are useful to you. Most vim questions are wildly googlable. Type in ":help", and read the description of how the command and navigation works. Then use it whenever you can't remember how every other command works.
Well as carb said, you aren't going to be writing code for hours and hours each day. As a project gets fuller, it's more navigation between files and manipulation of what is already there. The ability to move around lines with only one key or a key and an alternater (Shift more often than not) makes movement a blast. Searching for words around a file is as simple as a /. The ability to repeat past commands is just a ".". There are a variety of commands that when they are first presented to you looks like a mess. If you take a second and look at it it turns out to be really quite simple. Just vim commands are short and sweet and simple.
There is no recipe or anything to get really good at Vim. It's up to the person using it to get a firm handle on what is going on. Some times you just have to be curious and notice that there could be a performance tweak here and then research how to do it. Also, don't be afraid to make your own macros to take care of work for you. I have plenty of self defined macros. Taking all the work from someone else doesn't make it entirely yours. Tweaking and picking from tons of other vimrc's and the like can be interesting.
As a tid bit, make your own dotfiles repository on github. I have about 15-20 systems where my dotfiles directory is symlinked and as long as I have internet I can transfer around my perfect environment.
There is no recipe or anything to get really good at Vim. It's up to the person using it to get a firm handle on what is going on. Some times you just have to be curious and notice that there could be a performance tweak here and then research how to do it. Also, don't be afraid to make your own macros to take care of work for you. I have plenty of self defined macros. Taking all the work from someone else doesn't make it entirely yours. Tweaking and picking from tons of other vimrc's and the like can be interesting.
As a tid bit, make your own dotfiles repository on github. I have about 15-20 systems where my dotfiles directory is symlinked and as long as I have internet I can transfer around my perfect environment.
I intend to spend time with vim over the weekend and take-in some of the excellent input found on this thread.
The mental image I am developing now is that vim can be said to be efficient in a narrow sense. Perhaps that narrow definition is constrained to the file level. It's like a musical instrument to manipulate files. Once you know it well, it feels just like that. I am not saying that this is the only definition, it's just what I am coming-up with now.
Once we deviate from whatever the narrow definition of where vim is more efficient the claims start to fall apart. This doesn't happen because of vim but rather because it is the very nature of creating software: Things take time and saving keystrokes at the file-editing level isn't going to bring a project to completion six months earlier and with less bugs.
I wear at least two hats: developer and businessman. I am forced to look at things from both angles, because, well, I have to pay for the consequences of my own decisions. For example, if I succumb to my natural inclination to keep adding features it means that I might have ten programmers busy for weeks chasing an ever-moving project completion milestone. So, as a business person, I do my best to control these urges and look at things through a different equation. Eventually you have to call it "done" and move on.
Over the years I have never seen any code entry tool that truly makes a serious dent in software project timelines. Software projects are notorious for being late and over-budget. And this has absolutely nothing to do with the tools we use. Zero. A better editor or IDE will not make a dent on overall project timeline. Anyone who can figure out a way to solve that problem can become an "instant" billionaire.
The mental image I am developing now is that vim can be said to be efficient in a narrow sense. Perhaps that narrow definition is constrained to the file level. It's like a musical instrument to manipulate files. Once you know it well, it feels just like that. I am not saying that this is the only definition, it's just what I am coming-up with now.
Once we deviate from whatever the narrow definition of where vim is more efficient the claims start to fall apart. This doesn't happen because of vim but rather because it is the very nature of creating software: Things take time and saving keystrokes at the file-editing level isn't going to bring a project to completion six months earlier and with less bugs.
I wear at least two hats: developer and businessman. I am forced to look at things from both angles, because, well, I have to pay for the consequences of my own decisions. For example, if I succumb to my natural inclination to keep adding features it means that I might have ten programmers busy for weeks chasing an ever-moving project completion milestone. So, as a business person, I do my best to control these urges and look at things through a different equation. Eventually you have to call it "done" and move on.
Over the years I have never seen any code entry tool that truly makes a serious dent in software project timelines. Software projects are notorious for being late and over-budget. And this has absolutely nothing to do with the tools we use. Zero. A better editor or IDE will not make a dent on overall project timeline. Anyone who can figure out a way to solve that problem can become an "instant" billionaire.
You are making stuff up. Nobody is claiming that using Vim over Eclipse allows a product to be delivered earlier and with less bugs.
The Agile crowd makes that kind of claim, some language zealots also do.
The "saving keystrokes" argument is important for programmers because our work is very repetitive and we are lazy. It has nothing to do with the productivity of your team or the release date. Nothing. Because programmers don't care about all that. Chosing Vim over another editor is a matter of personal choice.
If you don't like Vim don't use it. Noone cares.
if you are interested, even remotely, try it in your free time.
But by all means don't project the effects of your delusions on random strangers: nobody is insisting that you use Vim instead of X. All the "Vim is awesome" comments or blog posts you have read are not attempts to bring you to our temple. They are just manifestations of our personal and often unreasonable "love" for Vim. No more, no less.
The Agile crowd makes that kind of claim, some language zealots also do.
The "saving keystrokes" argument is important for programmers because our work is very repetitive and we are lazy. It has nothing to do with the productivity of your team or the release date. Nothing. Because programmers don't care about all that. Chosing Vim over another editor is a matter of personal choice.
If you don't like Vim don't use it. Noone cares.
if you are interested, even remotely, try it in your free time.
But by all means don't project the effects of your delusions on random strangers: nobody is insisting that you use Vim instead of X. All the "Vim is awesome" comments or blog posts you have read are not attempts to bring you to our temple. They are just manifestations of our personal and often unreasonable "love" for Vim. No more, no less.
After doing a lot of work on a specific project, you aren't going to be writing code very frequently. Most of your work will go towards manipulating, editing, and applying minor (or major) fixes to your existing codebase.
When you aren't in insert mode, it's easy to navigate to specific lines (g), scan quickly through the document (^D, ^B), scan through lines (b,e), change/delete stuff (c,d,C,D,s,etc. Quick commands like ci" will Change Inside Quotes, so for example you can edit strings very quickly.), and search (/, , #, n, N).
As well, like tlunter said, vim is very portable. If you have to hop on someone else's computer to change some of their local code, there almost certainly* will be an editor that you can use quickly and efficiently. It also loads very quickly.
When you aren't in insert mode, it's easy to navigate to specific lines (g), scan quickly through the document (^D, ^B), scan through lines (b,e), change/delete stuff (c,d,C,D,s,etc. Quick commands like ci" will Change Inside Quotes, so for example you can edit strings very quickly.), and search (/, , #, n, N).
As well, like tlunter said, vim is very portable. If you have to hop on someone else's computer to change some of their local code, there almost certainly* will be an editor that you can use quickly and efficiently. It also loads very quickly.
"in the context of a non-trivial project, vi[m] offer no real gains, particularly when one considers timelines, code quality, bugs, costs, etc."
"Give us, vi[m] neophytes, steps to follow in order to understand how one might do a specific task more efficiently "
I believe this is the strawman that was being alluded to in the previous thread. Nobody is going around saying "Hey, if you don't use vim, you are producing less than I am!" Okay maybe some people do say that, but that's really not the reason people love vim.
The real reason (in my opinion, of course) has to do with flow. It's hard to explain, which is why these discussions tend to digress. But when you're in flow, or the zone, you don't want things like your text editor to get in your way. You want it to be a harmonious extension of your intentions to the machine. When you connect with vim, that is what you get. Other people might get that connection with emacs, or some other editor. But for the most part, you just don't get it with editors that don't allow a rich communication vocabulary between you and the machine.
Does flow matter on the scale of business deliverables within a project budget? Not really. It matters to the enjoyability of the creation experience that the programmers are involved in. They could probably still produce the work without that additional enjoyability, but less enjoyable work can sometimes lead to lower quality. And perhaps more importantly, it always leads to less joy.
For the past several years I've been using a keyboard that doesn't require me to move my hand away from the home row in order to manipulate the mouse cursor. There's a similarity there in that it reduces flow interruption. I've recently started learning vim because I see this same potential in it.
As for "recipes", there is a post here taken from the previous thread: http://www.viemu.com/a-why-vi-vim.html
"Give us, vi[m] neophytes, steps to follow in order to understand how one might do a specific task more efficiently "
I believe this is the strawman that was being alluded to in the previous thread. Nobody is going around saying "Hey, if you don't use vim, you are producing less than I am!" Okay maybe some people do say that, but that's really not the reason people love vim.
The real reason (in my opinion, of course) has to do with flow. It's hard to explain, which is why these discussions tend to digress. But when you're in flow, or the zone, you don't want things like your text editor to get in your way. You want it to be a harmonious extension of your intentions to the machine. When you connect with vim, that is what you get. Other people might get that connection with emacs, or some other editor. But for the most part, you just don't get it with editors that don't allow a rich communication vocabulary between you and the machine.
Does flow matter on the scale of business deliverables within a project budget? Not really. It matters to the enjoyability of the creation experience that the programmers are involved in. They could probably still produce the work without that additional enjoyability, but less enjoyable work can sometimes lead to lower quality. And perhaps more importantly, it always leads to less joy.
For the past several years I've been using a keyboard that doesn't require me to move my hand away from the home row in order to manipulate the mouse cursor. There's a similarity there in that it reduces flow interruption. I've recently started learning vim because I see this same potential in it.
As for "recipes", there is a post here taken from the previous thread: http://www.viemu.com/a-why-vi-vim.html
I am going to ignore the first part of your comment because, well, I asked that this thread not go that way. The problem with the other thread is that claims were made about vi efficiency and not one bit of data of any kind was provided to support these claims. Nobody learns this way. This thread is already very different as many have provided very interesting comments with valuable insight, including yourself.
I understand flow very well of course. I can't say that I've ever used an editor that prevented me to enter that state. I a not countering your statement, just providing my own experience.
Aside from programming I play the piano and classical guitar. When I play music I am in flow. That didn't happen until I had reasonable command of the instruments. With vi (or any other tool) the same is required. I wonder how much time it would take to go from vi neophyte to playing it like a piano? That initial phase is painful if you have to get work done.
I also understand the value of playing a good instrument and using good tools. And, while this value may not provide any hard quantifiable benefits to the project timeline it does provide benefits for the practitioner. The project might still be six months late, but there will be more daily enjoyment, if you will, for the practitioner to remain on focus. That could have value. Whether or not there is a difference between someone who has never touched vi and a vi expert remains to be determined. The vast majority of programmers don't use vi.
After reading your post and others on this thread my immediate reaction is that vi advocates might want to consider not characterizing vi as "more efficient" but rather highlight what it might do for a programmer. I can't come up with the words right now, but "more efficient", in my book, calls for having quantifiable data at the project level (not the file level).
We all know that saving a few keystrokes here and there isn't going to bring a project to conclusion any sooner. We had a project where we spent six months tracking down a bug that was due to a rounding error someone made in a calculation of lookup-table data used in a polyphase FIR filter module. It was one of those things that was right in front of you but nobody could see it. The project was late by an additional six months (it was already late) because of that bug. That's the kind of thing I think about when I say that saving a few keystrokes on the editor doesn't matter in the context of a project.
I'll read the article you pointed out and see what else I can learn.
Thanks for your input and valuable insight.
I understand flow very well of course. I can't say that I've ever used an editor that prevented me to enter that state. I a not countering your statement, just providing my own experience.
Aside from programming I play the piano and classical guitar. When I play music I am in flow. That didn't happen until I had reasonable command of the instruments. With vi (or any other tool) the same is required. I wonder how much time it would take to go from vi neophyte to playing it like a piano? That initial phase is painful if you have to get work done.
I also understand the value of playing a good instrument and using good tools. And, while this value may not provide any hard quantifiable benefits to the project timeline it does provide benefits for the practitioner. The project might still be six months late, but there will be more daily enjoyment, if you will, for the practitioner to remain on focus. That could have value. Whether or not there is a difference between someone who has never touched vi and a vi expert remains to be determined. The vast majority of programmers don't use vi.
After reading your post and others on this thread my immediate reaction is that vi advocates might want to consider not characterizing vi as "more efficient" but rather highlight what it might do for a programmer. I can't come up with the words right now, but "more efficient", in my book, calls for having quantifiable data at the project level (not the file level).
We all know that saving a few keystrokes here and there isn't going to bring a project to conclusion any sooner. We had a project where we spent six months tracking down a bug that was due to a rounding error someone made in a calculation of lookup-table data used in a polyphase FIR filter module. It was one of those things that was right in front of you but nobody could see it. The project was late by an additional six months (it was already late) because of that bug. That's the kind of thing I think about when I say that saving a few keystrokes on the editor doesn't matter in the context of a project.
I'll read the article you pointed out and see what else I can learn.
Thanks for your input and valuable insight.
I just think "efficient" is ill-defined. Nobody (or nearly nobody, I can't speak for everyone) that says vi[m] is more efficient is talking about project-level efficiency. They are talking about saving a few keystrokes (or more importantly a tiny amount of attention) when manipulating text. Manipulating text is just one part of writing software, but it's the part that developers want to spend the least amount of thought on, as it's (as you point out) not that important at the project level.
Being more efficient at manipulating text means less energy spent, which makes for happier programmers. So the more efficient text-editing is preferred by some, not because it leads to better software, but because it leads to better quality of life. And I stand by the statement that vi[m] is more efficient at manipulating text, while not disagreeing with you that it makes no difference at the project level.
Being more efficient at manipulating text means less energy spent, which makes for happier programmers. So the more efficient text-editing is preferred by some, not because it leads to better software, but because it leads to better quality of life. And I stand by the statement that vi[m] is more efficient at manipulating text, while not disagreeing with you that it makes no difference at the project level.
> Being more efficient at manipulating text means less energy spent, which makes for happier programmers. So the more efficient text-editing is preferred by some, not because it leads to better software, but because it leads to better quality of life. And I stand by the statement that vi[m] is more efficient at manipulating text, while not disagreeing with you that it makes no difference at the project level.
I can absolutely agree with you on that. Learning vi[m] in order to get to that level seems to be the hit lots of people are not willing to (or simply can't) take. In the context of a busy shop it makes almost no sense to bring productivity down to almost nothing while everyone has to slow down to learn a new tool (any tool, not just vi[m]). The only time one can justify this sort of thing is when there are real and measurable business or code quality benefits to the interruption. An example of that is sending everyone out to a one week course on a new technology. When they come back they absolutely rock. I've sent people out to take courses costing the company tens of thousands of dollars on more than one occasion. In every case it pays off within days.
I can't say that about vi[m] yet. Not wanting to voice opinion from a context of ignorance I will spend time over the weekend to force myself to dive into vim and see what I can learn. Happy programmers, hell, happy people, are always more fun to work with and be around. If vi[m] can bring that to the table I have no problem promoting its learning and usage at our shop (when we can afford to take the initial productivity hit while everyone learns).
I can absolutely agree with you on that. Learning vi[m] in order to get to that level seems to be the hit lots of people are not willing to (or simply can't) take. In the context of a busy shop it makes almost no sense to bring productivity down to almost nothing while everyone has to slow down to learn a new tool (any tool, not just vi[m]). The only time one can justify this sort of thing is when there are real and measurable business or code quality benefits to the interruption. An example of that is sending everyone out to a one week course on a new technology. When they come back they absolutely rock. I've sent people out to take courses costing the company tens of thousands of dollars on more than one occasion. In every case it pays off within days.
I can't say that about vi[m] yet. Not wanting to voice opinion from a context of ignorance I will spend time over the weekend to force myself to dive into vim and see what I can learn. Happy programmers, hell, happy people, are always more fun to work with and be around. If vi[m] can bring that to the table I have no problem promoting its learning and usage at our shop (when we can afford to take the initial productivity hit while everyone learns).
Most programmers who care that much about their tools will learn (at least partly) on their own time. I agree that it probably doesn't make sense to have a "learn vim" week at most companies.
You are one dedicated anti-vi troll. Seriously, bravo!
In looking for vi[m] tools for Vista 64 I came across this:
http://www.microsoft.com/en-us/download/details.aspx?id=2375...
older, but better explanation: http://technet.microsoft.com/en-us/library/cc779522(v=ws.10)...
And a blurb on how to go about enabling some of the functionality:
http://www.microsoft.com/en-us/download/details.aspx?id=2375...
older, but better explanation: http://technet.microsoft.com/en-us/library/cc779522(v=ws.10)...
And a blurb on how to go about enabling some of the functionality:
If you have Vista Enterprise or Ultimate, you can install the optional
"Subsystem for Unix Applications" (SUA). This is under Control Panel,
Programs and Features, Turn Windows Features On or Off. After you have
installed SUA on Vista, then download the "Utilities and SDK for SUA" from
Microsoft.com (the download URL is in the Start menu, after you install
SUA).
The SUA Utilities include vi, as well as all the standard Unix/Posix tools
like ls, cat, sed, awk, etc. There is also the gcc compiler, so you can
compile and run a wide range of open source Unix software on your Vista box.
You can also download SUA binaries and source code for many popular
Linux/Unix apps on Vista, from www.interopsystems.com - Apache, PostgreSQL,
OpenSSL, Squid etc - it's all there.
Unfortunately, SUA is not available for Home or Business editions of Vista.
If you have one of these editions, you can try using Vim, a very popular vi
clone (see www.vim.org). A Win32 version is availabel. In fact several Unix
distributions are now shipping vim as the standard editor, in place of the
classic vi (because vim has many useful extra features).
Vim is extremely regular, as well as extremely powerful.
The thing that makes me rage when I'm forced to use an editor other than vim is "Ctrl-RightArrow / Ctrl-LeftArrow".
Will it stop on spaces? Will it stop on commas? Will it stop on parenthesis? If I hit Ctrl-Right->Right->Right then Ctrl-Left->Left->Left do I end up back where I started?
I cannot fathom how people blindly accept that their editing movement operations are inconsistent. In case it's not clear, by default in windows most text editor areas do not "properly" return you to where you started with a bunch of Ctrl-Right/Ctrl-Left pairs (although I can't tell you at the moment what characters actually trigger this issue).
Finally, by being a "modal" editor... when you want to type letters and stuff, getting into insert mode is an extremely small price to pay in comparison to having 26 function keys under your fingertips at all times.
"""Vi has the advantage that most ordinary keys are connected to some kind of command for positioning, altering text, searching and so forth, either singly or in key combinations. Many commands can be touch typed without the use of ⇧ Shift,Ctrl or Alt. Other types of editors generally require the user to move their hands from the home row when touch typing:"""
...the idea being that when you're actively typing, vim is just as crappy of a text editor as anything else (notepad, bbedit, etc.) but when you're not typing you've got at least 26 letters which all do something, then 26 more because you can type shift.
q == record macro, w == move by word, e == end of word, r == replace character, etc, etc, etc. (don't make me type them all out, we'll be here a while! ;-)
The thing that makes me rage when I'm forced to use an editor other than vim is "Ctrl-RightArrow / Ctrl-LeftArrow".
Will it stop on spaces? Will it stop on commas? Will it stop on parenthesis? If I hit Ctrl-Right->Right->Right then Ctrl-Left->Left->Left do I end up back where I started?
I cannot fathom how people blindly accept that their editing movement operations are inconsistent. In case it's not clear, by default in windows most text editor areas do not "properly" return you to where you started with a bunch of Ctrl-Right/Ctrl-Left pairs (although I can't tell you at the moment what characters actually trigger this issue).
Finally, by being a "modal" editor... when you want to type letters and stuff, getting into insert mode is an extremely small price to pay in comparison to having 26 function keys under your fingertips at all times.
"""Vi has the advantage that most ordinary keys are connected to some kind of command for positioning, altering text, searching and so forth, either singly or in key combinations. Many commands can be touch typed without the use of ⇧ Shift,Ctrl or Alt. Other types of editors generally require the user to move their hands from the home row when touch typing:"""
...the idea being that when you're actively typing, vim is just as crappy of a text editor as anything else (notepad, bbedit, etc.) but when you're not typing you've got at least 26 letters which all do something, then 26 more because you can type shift.
q == record macro, w == move by word, e == end of word, r == replace character, etc, etc, etc. (don't make me type them all out, we'll be here a while! ;-)
> I cannot fathom how people blindly accept that their editing movement operations are inconsistent.
That can be a problem if you have to jump from platform to platform or work with IDE's that implement things in vastly different ways.
I jump between Windows and Mac all the time and for the longest time the Mac keyboard was infuriating. My solution was to re-map it to match, as much as possible, what I was used to. That may very well be the case with vim advocates. To be clear, this isn't about one or the other approach being better by any measure of the work. It's simply that one tends to prefer that which is familiar. That's just the way every person is wired. I've seen this across disciplines that have nothing whatsoever to do with programming. Resistance to change is a strong force. We tend to want to stay with what we know and reject change at a visceral level. And that's OK.
Your point are probably valid. I'll take the time to explore over the weekend. Thanks for taking the time to share your insights.
That can be a problem if you have to jump from platform to platform or work with IDE's that implement things in vastly different ways.
I jump between Windows and Mac all the time and for the longest time the Mac keyboard was infuriating. My solution was to re-map it to match, as much as possible, what I was used to. That may very well be the case with vim advocates. To be clear, this isn't about one or the other approach being better by any measure of the work. It's simply that one tends to prefer that which is familiar. That's just the way every person is wired. I've seen this across disciplines that have nothing whatsoever to do with programming. Resistance to change is a strong force. We tend to want to stay with what we know and reject change at a visceral level. And that's OK.
Your point are probably valid. I'll take the time to explore over the weekend. Thanks for taking the time to share your insights.
recently i learned that some developer successfully ported vim to windows 64 bit. i was mighty glad, installed it on a windows 8 machine and started to use vim right away, simply because dos's edit command doesn't provide features similar to vim.
i decided to write here how i use vim in no particular preference:
vim's J keystroke (that joins the line in succession with the one you're on) is the most frequent reason i use vim on whatever platform.
next, s/this/that/g search and replace is quick for regex based string replacements
next, vim -d file1 file2 visual difference is pretty great in console or in the gui mode (gvim)
next, on a unix system if you're dealing with C sources for a big project, ctags allows vim to provide the feature where you press CTRL-] and it takes you to the definition of that symbol. This is similar to other editor's right click and 'go to definition' context menu.
i'm not trying to sell vim to you or readers of HN; i'm simply advising to read :help in vim to the best of your abilities the same way you would read about other editor's help pages/cheat sheets and the sort to determine value for yourself. i do agree that examples sometimes enable you to associate with one or the other editor; i dislike using vim for editing all sorts of files. i use vim for things i can quickly get done in it, using other tools for whatever they're good at, if that makes sense.
i decided to write here how i use vim in no particular preference:
vim's J keystroke (that joins the line in succession with the one you're on) is the most frequent reason i use vim on whatever platform.
next, s/this/that/g search and replace is quick for regex based string replacements
next, vim -d file1 file2 visual difference is pretty great in console or in the gui mode (gvim)
next, on a unix system if you're dealing with C sources for a big project, ctags allows vim to provide the feature where you press CTRL-] and it takes you to the definition of that symbol. This is similar to other editor's right click and 'go to definition' context menu.
i'm not trying to sell vim to you or readers of HN; i'm simply advising to read :help in vim to the best of your abilities the same way you would read about other editor's help pages/cheat sheets and the sort to determine value for yourself. i do agree that examples sometimes enable you to associate with one or the other editor; i dislike using vim for editing all sorts of files. i use vim for things i can quickly get done in it, using other tools for whatever they're good at, if that makes sense.
>recently i learned that some developer successfully ported vim to windows 64 bit.
Do you have a link to the port?
Do you have a link to the port?
found it.
Well, as someone who's in the middle of writing his own blogging platform specifically so I can use Vim to write my posts...
The important thing that Vim does for me is to reduce to an absolute minimum the amount of keypresses it takes to write the code I want.
Simple example: It's a common practice when people are putting in blocks of comments to put in an eighty-character line of hashes to delineate it - something I'm sure every coder has seen. And it's not hard to just hold down the hash key until it's reached the end of the line. But it's far quicker and more reliable in vim: 80i#<ESC>
Say I'm editing code near the bottom of a screenful of text. I want to see a couple of lines that are just off the top of the screen. In most editors you'd hold down the "up" key until your cursor reached the top of the page, keep going until the lines you wanted were on show, then hold "down" until you got back to where you started.
In vim, Ctrl-Y a couple of times and you're done, without losing your place - your cursor stays in the current position, on the current line.
The regex-capable search + find&replace is invaluable - Earlier today I had to generate >100 tests based on information spread through multiple spreadsheet tabs. This would have been hours of work doing point&click copy-pasting, it was done in a few minutes courtesy of a couple of regexes.
Moving blocks of code around when refactoring is effortless: di} to delete all the code in the current JS function and copy it to the buffer, move to where you want the code to be, 'p' to put it in its new home.
The "snippets" plugin giving TextMate-style functionality is very useful, a big plus for vim's ability to be programmed, which I also use extensively. For example, we often need to look at information stored by our web application in a database. We used to have to either access it via the DB or use the web app itself to display a poorly-formatted static text output. I created a Vim command that retrieves the data, orders it, formats it, syntax hilights it, and makes it far easier to navigate & search.
I've used IDEs, I've used other editors, and Vim is simply better than all of them. IDEs in particular spend more time getting in the way than they do being useful. Vim is the closest thing there is to being able to take the code I have in my head and dump it straight into a computer.
And given the number of studies that show that a single interruption to a coder can result in a half-hour delay whilst he rebuilds his mental stack, that makes Vim a tool that can save you hours of productive time every single week.
The important thing that Vim does for me is to reduce to an absolute minimum the amount of keypresses it takes to write the code I want.
Simple example: It's a common practice when people are putting in blocks of comments to put in an eighty-character line of hashes to delineate it - something I'm sure every coder has seen. And it's not hard to just hold down the hash key until it's reached the end of the line. But it's far quicker and more reliable in vim: 80i#<ESC>
Say I'm editing code near the bottom of a screenful of text. I want to see a couple of lines that are just off the top of the screen. In most editors you'd hold down the "up" key until your cursor reached the top of the page, keep going until the lines you wanted were on show, then hold "down" until you got back to where you started.
In vim, Ctrl-Y a couple of times and you're done, without losing your place - your cursor stays in the current position, on the current line.
The regex-capable search + find&replace is invaluable - Earlier today I had to generate >100 tests based on information spread through multiple spreadsheet tabs. This would have been hours of work doing point&click copy-pasting, it was done in a few minutes courtesy of a couple of regexes.
Moving blocks of code around when refactoring is effortless: di} to delete all the code in the current JS function and copy it to the buffer, move to where you want the code to be, 'p' to put it in its new home.
The "snippets" plugin giving TextMate-style functionality is very useful, a big plus for vim's ability to be programmed, which I also use extensively. For example, we often need to look at information stored by our web application in a database. We used to have to either access it via the DB or use the web app itself to display a poorly-formatted static text output. I created a Vim command that retrieves the data, orders it, formats it, syntax hilights it, and makes it far easier to navigate & search.
I've used IDEs, I've used other editors, and Vim is simply better than all of them. IDEs in particular spend more time getting in the way than they do being useful. Vim is the closest thing there is to being able to take the code I have in my head and dump it straight into a computer.
And given the number of studies that show that a single interruption to a coder can result in a half-hour delay whilst he rebuilds his mental stack, that makes Vim a tool that can save you hours of productive time every single week.
One of the seemingly common threads I am seeing is that having vim available across platforms is an advantage to some. That certainly has value.
I can't really comment on the rest of your excellent post until I try some of these things out. I intend to spend some time with vim this weekend, try out some of the ideas presented in this thread and see what I can learn.
I can comment on this: "And given the number of studies that show that a single interruption to a coder can result in a half-hour delay whilst he rebuilds his mental stack, that makes Vim a tool that can save you hours of productive time every single week."
I've been programming since I was ten years old. I have well over twenty years of experience in the field, across multiple platforms, tools and languages. I started out with machine language. Not assembler, actually typing in hex instruction codes into a keypad. Back then, I used that approach a number of times to bootstrap a Forth system onto a newly built computer board (something like a 6502 board). One of the first things you do after that is write an editor (in Forth) so you can start moving faster.
I have to say that in all of this time I have never had an editor get in the way of the programming task to such an extent that it can be considered an interruption. Interruptions that disrupt the mental stack you refer to are very real and they suck, but, in my experience, the text editor is never the issue.
Again, thanks for your valuable input. I'll spend some time absorbing it over the weekend. I need to get a project out first. Damn priorities!
I can't really comment on the rest of your excellent post until I try some of these things out. I intend to spend some time with vim this weekend, try out some of the ideas presented in this thread and see what I can learn.
I can comment on this: "And given the number of studies that show that a single interruption to a coder can result in a half-hour delay whilst he rebuilds his mental stack, that makes Vim a tool that can save you hours of productive time every single week."
I've been programming since I was ten years old. I have well over twenty years of experience in the field, across multiple platforms, tools and languages. I started out with machine language. Not assembler, actually typing in hex instruction codes into a keypad. Back then, I used that approach a number of times to bootstrap a Forth system onto a newly built computer board (something like a 6502 board). One of the first things you do after that is write an editor (in Forth) so you can start moving faster.
I have to say that in all of this time I have never had an editor get in the way of the programming task to such an extent that it can be considered an interruption. Interruptions that disrupt the mental stack you refer to are very real and they suck, but, in my experience, the text editor is never the issue.
Again, thanks for your valuable input. I'll spend some time absorbing it over the weekend. I need to get a project out first. Damn priorities!
Three things gave a background to my decision to start learning Vim:
* A nagging desire to drop Mac OS X in favor of Linux and, therefore, the necessity to find an alternative to TextMate. * TextMate's learning curve is very flat and very short. After years of heavy usage, I was bored. * I've seen a couple of "magic" Vim screencasts that left me drooling like an idiot.
Because of the first point, I've spent a significant portion of 2009 trying out all the Linux/cross-platform editors/IDEs I could find: Gedit, Geany, Kate, Scribes, Redcar, Emacs, Vim, Eclipse, Komodo, IntelliJ IDEA… I've tried them all. I wanted completion (even basic), some kind of snippet system, themeability, fast navigation… and all of it was available in one form or the other in most of those editors/IDEs.
Because of the second point, the over all design of the editor, the steepness of its learning curve and all sorts of subjective details (keyboard friendlyness, scriptability, active community…) were also weighted when trying out all those editors/IDEs.
Because of the second and third point, I was very curious about Vim. It was the most "special", advanced users seemed to be able to fly and it was cross-platform. The String Calculator Kata In Python screencast (http://vimeo.com/8569257) by Gary Bernhardt, despite showing an heavily customized Vim, was mesmerizing. It's very subjective, I know, but I felt that Vim was just my kind of "special".
But yeah, it was really "special". All my attempts to use it had been very frustrating and I was about to settle on Eclipse.
Then came the right occasion: I had a totally empty week before me. Nothing to do at work, my kid was at his grandparents'… So I decided to give Vim a serious try.
I decided to start right at the beginning: $ vimtutor, which I did a good twenty times. After each session, I opened an old html or js or txt file and tried to apply my new knowledge. Of course the first day or two were very unproductive and frustrating but I had a lot of time and no obligation of prductivity so kept trying. After a week, I knew all the basic commands but I was definetely not ready. When, finally, I had some real work to do I naturally turned to my trusty old TextMate while I spent a couple of hours every night watching screencasts, reading tutorials, practicing and, above all, doing the biggest rookie mistake: trying to turn Vim into a TextMate clone.
I installed lots and lots of plugins, filled my .vimrc with hundreds of lines I didn't understand copypasted from people I didn't know and tried to map 1 to 1 Vim's and Textmate's keyboard shortcuts. After a few weeks at this rate, my Vim was an horrible and slow mess. It took a lamentably failed attempt to use Vim on a VPS for me to actually accept my failure and decide to go back to square one.
I deleted the content of my .vimrc and of my .vim/ and tried $ vimtutor again. I was a new "student": more open minded, more willing to learn. It was only at that time that I found myself suddenly blown away by the elegance of Vim's design and, yes, the SIMPLICITY of its language. Before that, aJc/ and Co. didn't really make much sense. After that, it took one month or so for me to finally make the switch after "solidifying" my newfound zen.
For me, it was mostly a question of design. And of being in the right state of mind.
So no, I won't prove you why Vim is better than X. That would be pointless because a. I don't care about you or the editor you use and b. I'm perfectly satisfied with the choice I made and I don't feel the need to convince myself through others that I was right.
Use whatever tool you prefer/know/need/can afford.
Instead I will show you a few things I THINK are cool.
* A nagging desire to drop Mac OS X in favor of Linux and, therefore, the necessity to find an alternative to TextMate. * TextMate's learning curve is very flat and very short. After years of heavy usage, I was bored. * I've seen a couple of "magic" Vim screencasts that left me drooling like an idiot.
Because of the first point, I've spent a significant portion of 2009 trying out all the Linux/cross-platform editors/IDEs I could find: Gedit, Geany, Kate, Scribes, Redcar, Emacs, Vim, Eclipse, Komodo, IntelliJ IDEA… I've tried them all. I wanted completion (even basic), some kind of snippet system, themeability, fast navigation… and all of it was available in one form or the other in most of those editors/IDEs.
Because of the second point, the over all design of the editor, the steepness of its learning curve and all sorts of subjective details (keyboard friendlyness, scriptability, active community…) were also weighted when trying out all those editors/IDEs.
Because of the second and third point, I was very curious about Vim. It was the most "special", advanced users seemed to be able to fly and it was cross-platform. The String Calculator Kata In Python screencast (http://vimeo.com/8569257) by Gary Bernhardt, despite showing an heavily customized Vim, was mesmerizing. It's very subjective, I know, but I felt that Vim was just my kind of "special".
But yeah, it was really "special". All my attempts to use it had been very frustrating and I was about to settle on Eclipse.
Then came the right occasion: I had a totally empty week before me. Nothing to do at work, my kid was at his grandparents'… So I decided to give Vim a serious try.
I decided to start right at the beginning: $ vimtutor, which I did a good twenty times. After each session, I opened an old html or js or txt file and tried to apply my new knowledge. Of course the first day or two were very unproductive and frustrating but I had a lot of time and no obligation of prductivity so kept trying. After a week, I knew all the basic commands but I was definetely not ready. When, finally, I had some real work to do I naturally turned to my trusty old TextMate while I spent a couple of hours every night watching screencasts, reading tutorials, practicing and, above all, doing the biggest rookie mistake: trying to turn Vim into a TextMate clone.
I installed lots and lots of plugins, filled my .vimrc with hundreds of lines I didn't understand copypasted from people I didn't know and tried to map 1 to 1 Vim's and Textmate's keyboard shortcuts. After a few weeks at this rate, my Vim was an horrible and slow mess. It took a lamentably failed attempt to use Vim on a VPS for me to actually accept my failure and decide to go back to square one.
I deleted the content of my .vimrc and of my .vim/ and tried $ vimtutor again. I was a new "student": more open minded, more willing to learn. It was only at that time that I found myself suddenly blown away by the elegance of Vim's design and, yes, the SIMPLICITY of its language. Before that, aJc/ and Co. didn't really make much sense. After that, it took one month or so for me to finally make the switch after "solidifying" my newfound zen.
For me, it was mostly a question of design. And of being in the right state of mind.
So no, I won't prove you why Vim is better than X. That would be pointless because a. I don't care about you or the editor you use and b. I'm perfectly satisfied with the choice I made and I don't feel the need to convince myself through others that I was right.
Use whatever tool you prefer/know/need/can afford.
Instead I will show you a few things I THINK are cool.
yy5p to duplicate the current line 5 times
:g/pattern/norm @m to apply macro m to all lines matching "pattern"
:'<,'>norm yss<li> to turn a bunch of visually selected lines into list items (the '<','> is added for you by Vim and the yss part is provided by Surround.vim)
:ts <tab> to select tags from a <tab>-navigable list
<C-x><C-l> (mapped to ,= here) to complete lines
<C-x><C-f> (mapped to ,: here) to complete filepaths
dat to remove a whole html tag
ci( to delete the content of parenthesis and enter insert mode
R to enter replace mode
<C-a> and <C-x> to increment/decrement a number (with an optional count)
<C-r>= in insert mode to insert the result of an expression
vatat to select a whole table row from within one of its cells
:s/foo/bar the best search/replace mechanism I've ever used
<C-o> and <C-i> to jump through the jumplist
ma 'a to create a mark and jump to it. that's pure beauty.
/?{}wWeEbBfFtT and all the other motions and text-objects that make moving around so horrible in every other editor
and so on…
This is, by far, the most intelligent and useful post I've seen in my attempt to get some answers and understand. I am as hard-headed and as anyone else. I am also as understanding as anyone else. Change only happens out of necessity and curiosity. I am curious to learn, otherwise I wouldn't spend all this time and take the abuse of some who choose to be total aholes and not take the kind of approach you have taken to at least help someone --not just me, but anyone who may have touched vi and failed-- understand where the strengths may be.
Based on your story it is clear that vi is not a weekend project. I am interested in learning so that I can have an opinion that is based on more than the "fuck this" reaction I have had over the last twenty years every time I've touched it on many platforms.
I am also impressed by your process and dedication to exploring the space. One can only respect that approach and the conclusion you reached. I too have used a ton of editors. For some reason I've never had the patience to really get into vi. But now I will. Because I owe it to myself to know what everyone is so impressed with. What happens from there is a different matter.
Also, thanks for not resorting to insults or calling me a troll as others who never seem to contribute anything of value have done.
Thanks again.
BTW, if you have more screencast links feel free to share them. I'd appreciate it and I am sure that others who are reading this and might have had the same level of rejection of vi would too.
Based on your story it is clear that vi is not a weekend project. I am interested in learning so that I can have an opinion that is based on more than the "fuck this" reaction I have had over the last twenty years every time I've touched it on many platforms.
I am also impressed by your process and dedication to exploring the space. One can only respect that approach and the conclusion you reached. I too have used a ton of editors. For some reason I've never had the patience to really get into vi. But now I will. Because I owe it to myself to know what everyone is so impressed with. What happens from there is a different matter.
Also, thanks for not resorting to insults or calling me a troll as others who never seem to contribute anything of value have done.
Thanks again.
BTW, if you have more screencast links feel free to share them. I'd appreciate it and I am sure that others who are reading this and might have had the same level of rejection of vi would too.
HTH.
There are many screencasts available on the net, paid and free. The best ones happen to be free.
Drew Neil's screencasts at http://vimcasts.org/ are laser-cut, focused and short. Each video is about one or two specific use-case so you don't get overwhelmed by dozens of "cryptic" commands. The production value is amazing (not in the Michael Bay meaning of the word).
Derek Wyatt's Vim Tutorial Videos at http://www.derekwyatt.org/vim/vim-tutorial-videos/ are the opposite: messy, lighthearted, funny, hysterical and packed with gold nuggets. You'll probably need to watch them a few times if you really want to extract practical knowledge.
Peepcode has three Vim-related screencasts but I think they are really bad, specially the "Play-by-Play" one.
Yes. Vim is not a weekend project. There's no way you can reach your previous level of productivity in one weekend or two.
May I suggest you, based on my own experience, to not install any plugin and not copy someone else .vimrc? Play around with $ vimtutor, exercise on random files (not on serious stuff), read the help (:help<Enter>), watch a bunch of screencasts to get the feel of what it's all about.
After the weekend is over you will either be craving for more or be disgusted.
Consider both outcomes as a succes and move on to the next step.
There are many screencasts available on the net, paid and free. The best ones happen to be free.
Drew Neil's screencasts at http://vimcasts.org/ are laser-cut, focused and short. Each video is about one or two specific use-case so you don't get overwhelmed by dozens of "cryptic" commands. The production value is amazing (not in the Michael Bay meaning of the word).
Derek Wyatt's Vim Tutorial Videos at http://www.derekwyatt.org/vim/vim-tutorial-videos/ are the opposite: messy, lighthearted, funny, hysterical and packed with gold nuggets. You'll probably need to watch them a few times if you really want to extract practical knowledge.
Peepcode has three Vim-related screencasts but I think they are really bad, specially the "Play-by-Play" one.
Yes. Vim is not a weekend project. There's no way you can reach your previous level of productivity in one weekend or two.
May I suggest you, based on my own experience, to not install any plugin and not copy someone else .vimrc? Play around with $ vimtutor, exercise on random files (not on serious stuff), read the help (:help<Enter>), watch a bunch of screencasts to get the feel of what it's all about.
After the weekend is over you will either be craving for more or be disgusted.
Consider both outcomes as a succes and move on to the next step.
Will do. I am planning on hitting-up vimtutor later today after the kids' Saturday activities are over. Fishing trip tomorrow is a priority, so vim will have to take a low priority to real life but I might manage to mess with it at night. Once again, thanks for your input.
So? How did it go?
I am always one interested in learning. And that is why I decided to launch this thread. To be clear, I am not interested in engaging in "mine is better than yours" discussions that invariably lead to flame wars.
The intent is to hear from vi[m] expert users on the reasons those of us who, like me, only touch vi[m] when absolutely forced to, or others who chose to avoid vi[m] or barely know anything about these editors should seriously consider what vi[m] have to offer.
I propose that posts should take the form of reproducible recipes. Give us, vi[m] neophytes, steps to follow in order to understand how one might do a specific task more efficiently using vi[m]. Please don't engage in comparing it to anything else. If we keep it to vi[m] recipes then this thread stands a chance of becoming an educational resource for those of us not familiar with these methods.
This also means that making claims about vi[m] efficiency supported by saying something akin to "every programmer who uses vi[m] thinks so" are not acceptable. Only recipes.
Also, in the interest of fairness, the recipes should work with unmodified vi[m]. Requiring the loading of plug-ins of various kinds muddles things as the same could be true of other editors.
In addition to this, let's not talk about things like memory foot print or binary size. With today's multi-gigahertz-multi-gigabyte computers this really is immaterial.
A recipe could start by suggesting to clone a certain github repository, then opening a specific file with vi[m] and then offering-up a series of commands that show how to derive efficiency gains from vi[m].
On my end, I have access to OSX, Linux, Irix, Solaris and emulators on Windows machines. Other readers might only have one platform available. Please indicate if your recipe, for some reason, requires a specific platform.
Finally, please don't comment on my introductory (first) paragraph. Only recipes and discussions that ask questions or offer clarifications on the recipe in question.
Thanks.