3 ms·

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

by tlunter 14y ago

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?

robomartin 14y ago
> 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.
- carb 14y ago
  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.
- waneb 14y ago
  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.
- tlunter 14y ago
  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.
  - robomartin 14y ago
    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.

by tlunter 14y ago

robomartin 14y ago

> 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.

carb 14y ago
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.
waneb 14y ago
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.
tlunter 14y ago
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.
- robomartin 14y ago
  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.