Don't ever start using vi. After you do, any text editor that you are forced to use that doesn't have vi key bindings will give you fits and make you cry.
Learning vi is your standard process of enlightenment and elation followed by a lifetime of disappointment. Think about how you'd feel if you ate the best meal of your life at age 13, and the restaurant where you ate it went out of business the next day.
You'll be frustrated by all other software. You'll wander around trying to explain to other people why the thing you had was so good, and it was so easy, and that nothing else compares, and wouldn't it be great if everyone did things this way.
I learned the bare minimum required to use vi. Insert, find, override-save... That's pretty much it. When vi is the only option, it's good enough; otherwise I'm free to use different editors.
Don't ever start using emacs. After you do, any text editor that you are forced to use that doesn't have emacs key bindings will give you fits and make you cry.
Learning emacs is your standard process of enlightenment and elation followed by a lifetime of disappointment. Think about how you'd feel if you ate the best meal of your life at age 13, and the restaurant where you ate it went out of business the next day.
You'll be frustrated by all other software. You'll wander around trying to explain to other people why the thing you had was so good, and it was so easy, and that nothing else compares, and wouldn't it be great if everyone did things this way.
> Do whatever you want. Don't learn it if you feel it's too much effort just for nothing. Learn emacs instead. Or stay in your IDE using a lousy editor. Whatever.
Why do all articles about how wonderful vi is end with condescension?
Anyway: vi -> fast editing. IDE -> fast maintenance. I know which one I'd choose. The text editing features of an IDE is not why people choose to use IDEs (note: of course this helps best if you use a well-supported statically typed language - a Ruby IDE can't be as awesome as a Java IDE).
Also, there could perfectly well be good IDEs with good Vim key binding support. This would be a wonderful mix of two worlds, and finally end this stupid discussion. I believe at least Qt Creator has a half-decent FakeVim mode baked in.
"Why do all articles about how wonderful vi is end with condescension?"
Because one way to get someone over the initial learning hump is to "encourage" them by challenging their manhood. Same principle behind a boot camp sergeant telling every single incoming group that they are the worst bunch of nambypamby girliemen he's ever seen and he's been in this army for 25 years and that he will consider it a personal failure if he doesn't cause each and every one of you to quit in a crying mess. You're supposed to be motivated to try your best in the hope that he'll begrudgingly concede at the end that you didn't suck after all.
It works, but it has the side effect of creating a strong tribal identity among those who pass the bar, an "us" who are good enough to make it and the "them" who didn't. The military deliberately exploits this side effect; I'm less convinced it's a good idea in a programmer context.
I mostly use Eclipse with the Emacs+ plugin for code development these days. Emacs+ provides an almost flawless Emacs experience, except for that fact that Eclipse is kind of a pain in the butt and often sluggish at manipulating text. It's sluggishness does interfere with my thought processes. Eclipse is very helpful for some things, but it would have been oh so much nicer if the features of Eclipse had been incorporated into something with the fluidity of Emacs. It's too bad that Lucid went out of business.
I've never really felt comfortable in vi. I first started using it in 1989 at home, used it throughout college, and then used it on-and-off during my career, but it's never really felt powerful compared to a GUI editor.
I want a scrollbar. I want a list of files in my project that I can just click on to open. I want tabs I can click. I want multiple windows that I can alt-tab to. And since I spend most of my time thinking and modifying code, I'm more often than not thinking in terms of tweaks and copy/pasting between files rather than "replace in this block of 3 words". A mouse and GUI just feels a lot more natural to me, even after 20 years of vi.
I'm with you. I want tabs, I want multiple windows, I want an easy list of project files, and I don't want to waste time thinking about editing. That's why I use vim.
If anyone is looking for tabs in vi, try out the (you'll never guess) tab feature in vi http://vimdoc.sourceforge.net/htmldoc/tabpage.html . What is great is that text completion (ctrl-p) works across tabs, so if you are using a library, open it up in a tab and you can ctrl-p away.
For extra points, learn to use hjkl and map your arrow keys to switch tabs.
I'm with you. I think an equivalent post could have been written on how programming in GUI is much better. What it comes down to is pretty boring and unsatisfying-- both have strengths and weaknesses, and these depend on the specific application.
if you're on linux, ctrl+shift+T usually brings up a new terminal window if you're running a desktop. you can alt+tab between these just like you can alt+tab between GUI editor windows.
Just the opposite. I find all that distracting. My hands never leave the keyboard. The mouse is a nuisance. I'm far more productive without all the GUI crap.
Whenever I am using a program other than vim I feel clumsy.
Plugins for Eclipse, Chrome and so on will only bring you so far. The other way around, namely turning vim into a multipurpose IDE does not satisfy my needs. One needs to admit that some features (refactoring support in Eclipse for example) cannot be matched by the available vim plugins. I know there are other solutions, like eclim, but I am looking for something more universal (think of using vim bindings in your email client).
This is why I have been thinking about implementing a vim emulation layer recently, so that every program can profit from vim keybindings. Basically this would be implemented as some form of keygrabber that would translate vim specific commands into regular ones.
Does anyone know of related pre-existing projects one could use as a reference. A quick google search did not deliver any results for me.
I use vim for about a year or more, and I like it, however I'm still having trouble with copying and pasting tiny fragments of text. Maybe someone can help me out with this?
1) If I yank a line with yy, pressing P or p will insert the text into a new line.
2) If I go to visual mode and select a region, yank it with y, then press p/P, it gets it inserted into the current line.
That is, vim preserves new lines.
What I can't figure out is how to paste into the current line in the first case, and, vice-versa, how to easily paste into a new line in the second case (without doing :put, or opening a new line).
I know this will be an unpopular comment, but my whole problem with it is actually the attitude of those that use it. After reading the article, I was really impressed and imagining all the ways it could help me after what, 8 years of coding into an IDE; and then I got to this:
"Do whatever you want. Don't learn it if you feel it's too much effort just for nothing. Learn emacs instead. Or stay in your IDE using a lousy editor. Whatever. But in any case, don't ever claim again that those 'vi guys are nutheads' - I hope that I have succeeded in showing you why they (we) stick to it, and you should at least be able to understand its power, even if you prefer to stay away from it."
I used vim for about 9 or 10 years before I switched to emacs. From my perspective people use vim because they haven't tried emacs yet (I kid!).
I still have the muscle memory for vi and that's what these sorts of editors rely on to be effective with them. Once you get enough practice the editor practically disappears and it becomes more about the text on the screen... almost like you are manipulating it directly with your mind.
I'd be interested to know how much of the stuff presented in the article is actually present in plain vi (not vim). If you mean vim, then say vim, not vi. They are two different things.
What I want to know: how good is the best autocompletion available? Does it stack up to Visual Studio's Intellisense? (For statically typed languages, that is; Intellisense doesn't work very well for eg Javascript).
Reading the article and the comments here, I came to the conclusion that I seemingly don't really use vi. As in: I don't live in it.
On a typical day, I work with my files using grep, awk, bash, python, sed, make, cat, xargs, etc. And, of course, vi.
But I don't really use it like some (most?) people here seem to do. I don't list and navigate through files in vi (I use tree, ls and find for that). When I use vi, it's mostly for short bursts of manual editing. Occasionally, vim's syntax highlighting comes in handy - but that's about it.
Don't get me wrong: that is exactly why I _love_ vi. It starts fast[0]. It fits in pretty well with the rest of the unix environment (it can read stdin, for example; and with vim you can open multiple files given on the command line - and you can construct that file list with any of the standard unix tools, of course).
So, for me, the question "IDE or vi" ends much earlier. I don't even come to the point where I could discuss editing features. Can't read from stdin? Doesn't start in less than 1 second? Doesn't fit into my work-flow.
Of course, vi(m) is a great editor, for all the reasons mentioned here and in the article. But the unix user-land has some great tools, too. And it includes vi. So it is by definition an even better editor than vi. :-)
So that's what I use.
[0] Believe it or not, emacs starts still too slow for me. These one or two seconds tend to disrupt me a lot (I've tried it, with GNU emacs). And, as I said before, I invoke my editor pretty often, maybe 50 times a day.
If you use vim then I highly recommend mapping spacebar to page-down and shift-spacebar to page-up. This key is kinda useless otherwise and super-helpful afterwards. It is also the largest key on your keyboard. usability++
I'm realizing that the distinction between vim/emacs and typical IDE editors is entropy. Vim is extraordinarily precise - very low entropy at all times. An IDE editor is constantly moving between high entropy (e.g. mouse motion) and low entropy (e.g. the interpretation of the mouse motion as a precise command). This implies that vim appeals to minds that desire constant precision, and GUI editors appeal to minds that prefer to vacillate between levels of precision.
Decoupled from this is the question of which pattern of thought lends itself to being a better programmer. There is a good argument either way: staying at a very precise level of thought is wonderful when solving problems; and yet it is better to loosen up when figuring out which problems to solve.
I tend to take the view that a programmer's actions while programming should ideally be unambiguous, precise, and regular at all times. Higher level thought should have a distinct place, time and another set of tools (pencil and paper being foremost among the alternatives).
One of the great things about vim is that even if you use it as your regular editor (I use MacVim), you tend to learn something new every time you read a new article. Today I learned about the '.' command.
I really don't get how its more efficient than a modern editor!
I use vi(m?) when I am working on a unix/linux/mac terminal and have done so for 10+ years. But I never bothered learning it properly so I only know a handful or two of commands. So I can't appreciate both perspectives clearly.
However, how can it be faster and more efficient to edit in vi than in a modern editor? I'd assume that if you can use multi gesture scrolling, point and click location, the modern editor type keyboard shortcuts (with multiple keys pressed) that it would lend itself to be faster to work with and more "efficient" somehow (hard to explain).
Would love to know what vi-people think about that because I am most likely wrong (as I said, very one-sided experience) but would love to get that level of detail (I don't think the story was iron clad on that point).
Is there anyone who has switched from many years of very happy vi onto modern editors and love that more?
I feel like such a tool for saying this, because I thought people who said this were tools before I 'got it'. Taking your fingers off the keyboard and to the mouse and trackpad is slow. I now even get how moving your fingers to the arrow keys is slow. I never thought I would believe it, but somehow here I am, spouting the same nonsense.
It's true. I think there is just some mind-body-editor connection that develops with vi(m) usage (and emacs, I don't know). When you really start thinking in vim, your mind starts describing what you need to do in vim commands, that magically flow out of your fingers, and vim responds.
In other editors, for any task I need to do, instead of telling my editor to do something, I have to show my editor how to do it by selecting text and menu items with the mouse, it just feels clumsy.
Once the keystrokes are muscle memory, it's impossible to beat with point and click in terms of speed.
That's just an opinion from a vim novice that can never go back.
To start with, the way vim keystrokes combine is pretty nifty. To move forward a word, w. To delete the next word, dw. To delete the next 6 words, 6dw. To move to the next "g" character on the line, fg. To delete everything to that character, dfg. To delete everything inside the parens surrounding the cursor, di(. Something I do a lot with viemu in ms sql: Select everything inside parens with vi(, then hit F5 to execute the subquery.
But it got really fun when I started using macros. Once you're doing everything with keystrokes and text objects, you can record a macro while you're doing it. So, keeping with sql, let's say I want an update statement.
First I use an IDE feature to give me a list of all columns in a table, comma-delimited.
qa starts recording a macro into register a
Wi<return> advances to the next column name and inserts a carriage return
<Esc> q stops recording macro
10@a plays the macro ten times
Now I've got each column on a different line. I go back to the first line.
qw starts recording a macro into register w
ia.<Esc> puts "a." at the beginning of the line
yw copies the column name
A = b.<Esc> goes to end of line and adds " = b."
pA, pastes the column name and adds a comma to the end
j^q moves to beginning of next line and stops macro recording
10@w does the same macro ten more times
Now with a few keystrokes, I've changed this:
column1, column2, column3, ...
To this:
a.column1 = b.column1,
a.column2 = b.column2,
a.column3 = b.column3, ...
And the key point is, I did it without having to think about it much. I used the same editing techniques I would have used to make that change for just one line, and with half a dozen extra keystrokes I made it apply to as many lines as I needed.
Possibly I made small mistakes in the exact keystrokes above. When doing it for real, you see all the changes on that first line as you do them, so if something isn't quite right, just hit u to undo and keep going. It's so easy, I can record and replay new macros all the time. I almost never have to do repetitive editing.
Another trick, not available in viemu but available in vim: select a bunch of lines, then type :norm and your next editing commands after that will get applied to all the lines. For example, to add a comma to the end of every selected line, :norm A,
I've used Vi(m) enough to know that I'm far more efficient in an editor designed to work with my OS.
Knowing Vi (or Emacs) is essential as a software developer, but using it as your local code editor has never made sense to me.
What most people who pontificated about Vi/Emacs/editor-of-choice often fail to realize is that there isn't a "One True Way To Do Things Bestest". Everyone works differently. Using Vi for 30+ hours isn't going to make me a better developer - and it certainly isn't going to speed up anything.
I'm extremely passionate about vim, and I cannot type with a plain QWERTY keyboard. It's really not a big deal. I remap h,j,k,l to d,h,t,n (and n to l so I can search) and I'm off to go.
The one problem I have is that my vimrc/.vim stuff is all customized far enough that I can never use any of the vim-like emulated modes in other text editors. I think evil-mode may be possible if I wanted to learn how to configure emacs at all, but it's generally not worth the hassle. I'm not sure about the particular Visual Studio plugin that the link is to, but one of the two doesn't allow remaps, for instance. It's generally not a problem to use j/k for short periods of time at least. My big problem Dvorak wise is Nethack which is sort of a pain. I bought a Qido USB layout switcher to make games like that possible.
Interesting article, I have always been interesting in moving to Vim, and this article all but sealed the deal for me. The only problem being I don't really see how useful this would be for general notepad usage. I understand the author of this article is selling his plugin for Visual Studio, and this is a marvellous way to do it. Is there any other way to integrate vim with Visual Studio 2008 without purchasing his ViEmu? I would love to start learning vim but I doubt a trial would be enough, and I don't see most of the other attributes he covered ('.' for example) being very useful in daily notetaking.
First, you understand how and why it is modal. Then you learn simple commands for movement and editing.
Then you learn all the meta-commands. All of these building blocks are only limited by your creativity of combining them to get what you want done. The more commands and tricks you know, the more you can slice and dice text, code, logs, whatever inside your editor (without leaving it).
I guess it's just a Unix/neckbeard thing. This is how the rest of Unix is designed, so why not the editor.
A couple of years ago I was recommended to read this article as I was doubting if vim was anything for me.
It convinced me to give it a try and after two weeks of learning it felt I could never go back. Since then I have vimified everything I can.
Later I have recommended this article to others of whom some have had similar experiences...
The author does a fine job describing the vim-philosophy instead of just a bag of tricks.
[+] [-] drblast|14 years ago|reply
Learning vi is your standard process of enlightenment and elation followed by a lifetime of disappointment. Think about how you'd feel if you ate the best meal of your life at age 13, and the restaurant where you ate it went out of business the next day.
You'll be frustrated by all other software. You'll wander around trying to explain to other people why the thing you had was so good, and it was so easy, and that nothing else compares, and wouldn't it be great if everyone did things this way.
Exactly like the author of this article.
You have been warned.
[+] [-] Florin_Andrei|14 years ago|reply
[+] [-] metaobject|14 years ago|reply
Learning emacs is your standard process of enlightenment and elation followed by a lifetime of disappointment. Think about how you'd feel if you ate the best meal of your life at age 13, and the restaurant where you ate it went out of business the next day.
You'll be frustrated by all other software. You'll wander around trying to explain to other people why the thing you had was so good, and it was so easy, and that nothing else compares, and wouldn't it be great if everyone did things this way.
You have been warned.
[+] [-] andrewvc|14 years ago|reply
[+] [-] tomjen3|14 years ago|reply
[+] [-] rgraham|14 years ago|reply
Or maybe you'll move on and it isn't that big of a deal.
You have been warned.
[+] [-] artursapek|14 years ago|reply
[+] [-] Riesling|14 years ago|reply
See my post below[0]. Your input would be appreciated.
[0]http://news.ycombinator.com/item?id=3543011
[+] [-] singular|14 years ago|reply
;-)
[+] [-] skrebbel|14 years ago|reply
Why do all articles about how wonderful vi is end with condescension?
Anyway: vi -> fast editing. IDE -> fast maintenance. I know which one I'd choose. The text editing features of an IDE is not why people choose to use IDEs (note: of course this helps best if you use a well-supported statically typed language - a Ruby IDE can't be as awesome as a Java IDE).
Also, there could perfectly well be good IDEs with good Vim key binding support. This would be a wonderful mix of two worlds, and finally end this stupid discussion. I believe at least Qt Creator has a half-decent FakeVim mode baked in.
[+] [-] jerf|14 years ago|reply
Because one way to get someone over the initial learning hump is to "encourage" them by challenging their manhood. Same principle behind a boot camp sergeant telling every single incoming group that they are the worst bunch of nambypamby girliemen he's ever seen and he's been in this army for 25 years and that he will consider it a personal failure if he doesn't cause each and every one of you to quit in a crying mess. You're supposed to be motivated to try your best in the hope that he'll begrudgingly concede at the end that you didn't suck after all.
It works, but it has the side effect of creating a strong tribal identity among those who pass the bar, an "us" who are good enough to make it and the "them" who didn't. The military deliberately exploits this side effect; I'm less convinced it's a good idea in a programmer context.
[+] [-] skrebbel|14 years ago|reply
That's cool. Also puts what I took for condescension in a different light.
Anyone used it? I might consider learning vi bindings decently if I can keep getting all the IDE goodness.
[+] [-] nessus42|14 years ago|reply
[+] [-] njharman|14 years ago|reply
Saying that "editor/IDE with vim keybindings" is as good as vim. Is like saying a Honda Civic painted red is as good as a Ferrari f70.
[+] [-] kstenerud|14 years ago|reply
I want a scrollbar. I want a list of files in my project that I can just click on to open. I want tabs I can click. I want multiple windows that I can alt-tab to. And since I spend most of my time thinking and modifying code, I'm more often than not thinking in terms of tweaks and copy/pasting between files rather than "replace in this block of 3 words". A mouse and GUI just feels a lot more natural to me, even after 20 years of vi.
[+] [-] sofal|14 years ago|reply
[+] [-] herge|14 years ago|reply
For extra points, learn to use hjkl and map your arrow keys to switch tabs.
[+] [-] tomjen3|14 years ago|reply
Until you have twenty files open and you can't find the right one (will happen sooner than you think, at least on largeish projects).
[+] [-] karpathy|14 years ago|reply
[+] [-] splat|14 years ago|reply
[+] [-] ilaksh|14 years ago|reply
[+] [-] vacri|14 years ago|reply
[+] [-] drhowarddrfine|14 years ago|reply
[+] [-] Riesling|14 years ago|reply
Plugins for Eclipse, Chrome and so on will only bring you so far. The other way around, namely turning vim into a multipurpose IDE does not satisfy my needs. One needs to admit that some features (refactoring support in Eclipse for example) cannot be matched by the available vim plugins. I know there are other solutions, like eclim, but I am looking for something more universal (think of using vim bindings in your email client).
This is why I have been thinking about implementing a vim emulation layer recently, so that every program can profit from vim keybindings. Basically this would be implemented as some form of keygrabber that would translate vim specific commands into regular ones.
Does anyone know of related pre-existing projects one could use as a reference. A quick google search did not deliver any results for me.
[+] [-] dchest|14 years ago|reply
1) If I yank a line with yy, pressing P or p will insert the text into a new line.
2) If I go to visual mode and select a region, yank it with y, then press p/P, it gets it inserted into the current line.
That is, vim preserves new lines.
What I can't figure out is how to paste into the current line in the first case, and, vice-versa, how to easily paste into a new line in the second case (without doing :put, or opening a new line).
[+] [-] electrichead|14 years ago|reply
"Do whatever you want. Don't learn it if you feel it's too much effort just for nothing. Learn emacs instead. Or stay in your IDE using a lousy editor. Whatever. But in any case, don't ever claim again that those 'vi guys are nutheads' - I hope that I have succeeded in showing you why they (we) stick to it, and you should at least be able to understand its power, even if you prefer to stay away from it."
[+] [-] agentultra|14 years ago|reply
I still have the muscle memory for vi and that's what these sorts of editors rely on to be effective with them. Once you get enough practice the editor practically disappears and it becomes more about the text on the screen... almost like you are manipulating it directly with your mind.
Fun article. :)
[+] [-] zokier|14 years ago|reply
[+] [-] itmag|14 years ago|reply
[+] [-] rwos|14 years ago|reply
On a typical day, I work with my files using grep, awk, bash, python, sed, make, cat, xargs, etc. And, of course, vi.
But I don't really use it like some (most?) people here seem to do. I don't list and navigate through files in vi (I use tree, ls and find for that). When I use vi, it's mostly for short bursts of manual editing. Occasionally, vim's syntax highlighting comes in handy - but that's about it.
Don't get me wrong: that is exactly why I _love_ vi. It starts fast[0]. It fits in pretty well with the rest of the unix environment (it can read stdin, for example; and with vim you can open multiple files given on the command line - and you can construct that file list with any of the standard unix tools, of course).
So, for me, the question "IDE or vi" ends much earlier. I don't even come to the point where I could discuss editing features. Can't read from stdin? Doesn't start in less than 1 second? Doesn't fit into my work-flow.
Of course, vi(m) is a great editor, for all the reasons mentioned here and in the article. But the unix user-land has some great tools, too. And it includes vi. So it is by definition an even better editor than vi. :-)
So that's what I use.
[0] Believe it or not, emacs starts still too slow for me. These one or two seconds tend to disrupt me a lot (I've tried it, with GNU emacs). And, as I said before, I invoke my editor pretty often, maybe 50 times a day.
[+] [-] davvid|14 years ago|reply
[+] [-] javajosh|14 years ago|reply
Decoupled from this is the question of which pattern of thought lends itself to being a better programmer. There is a good argument either way: staying at a very precise level of thought is wonderful when solving problems; and yet it is better to loosen up when figuring out which problems to solve.
I tend to take the view that a programmer's actions while programming should ideally be unambiguous, precise, and regular at all times. Higher level thought should have a distinct place, time and another set of tools (pencil and paper being foremost among the alternatives).
[+] [-] maxerickson|14 years ago|reply
[+] [-] boofar|14 years ago|reply
http://www.derekwyatt.org/vim/vim-tutorial-videos/
[+] [-] brown9-2|14 years ago|reply
Also, old discussion on same article: http://news.ycombinator.com/item?id=151637
[+] [-] qdog|14 years ago|reply
Been manually indenting stuff with :<line1>,<line2>,s/^/\t/ for years now, oof.
[+] [-] tkellogg|14 years ago|reply
[+] [-] gbog|14 years ago|reply
[+] [-] daniel_iversen|14 years ago|reply
I use vi(m?) when I am working on a unix/linux/mac terminal and have done so for 10+ years. But I never bothered learning it properly so I only know a handful or two of commands. So I can't appreciate both perspectives clearly.
However, how can it be faster and more efficient to edit in vi than in a modern editor? I'd assume that if you can use multi gesture scrolling, point and click location, the modern editor type keyboard shortcuts (with multiple keys pressed) that it would lend itself to be faster to work with and more "efficient" somehow (hard to explain).
Would love to know what vi-people think about that because I am most likely wrong (as I said, very one-sided experience) but would love to get that level of detail (I don't think the story was iron clad on that point).
Is there anyone who has switched from many years of very happy vi onto modern editors and love that more?
Thanks..
[+] [-] jimrhoskins|14 years ago|reply
It's true. I think there is just some mind-body-editor connection that develops with vi(m) usage (and emacs, I don't know). When you really start thinking in vim, your mind starts describing what you need to do in vim commands, that magically flow out of your fingers, and vim responds.
In other editors, for any task I need to do, instead of telling my editor to do something, I have to show my editor how to do it by selecting text and menu items with the mouse, it just feels clumsy.
Once the keystrokes are muscle memory, it's impossible to beat with point and click in terms of speed.
That's just an opinion from a vim novice that can never go back.
[+] [-] DennisP|14 years ago|reply
But it got really fun when I started using macros. Once you're doing everything with keystrokes and text objects, you can record a macro while you're doing it. So, keeping with sql, let's say I want an update statement.
First I use an IDE feature to give me a list of all columns in a table, comma-delimited.
qa starts recording a macro into register a
Wi<return> advances to the next column name and inserts a carriage return
<Esc> q stops recording macro
10@a plays the macro ten times
Now I've got each column on a different line. I go back to the first line.
qw starts recording a macro into register w
ia.<Esc> puts "a." at the beginning of the line
yw copies the column name
A = b.<Esc> goes to end of line and adds " = b."
pA, pastes the column name and adds a comma to the end
j^q moves to beginning of next line and stops macro recording
10@w does the same macro ten more times
Now with a few keystrokes, I've changed this: column1, column2, column3, ...
To this:
a.column1 = b.column1,
a.column2 = b.column2,
a.column3 = b.column3, ...
And the key point is, I did it without having to think about it much. I used the same editing techniques I would have used to make that change for just one line, and with half a dozen extra keystrokes I made it apply to as many lines as I needed.
Possibly I made small mistakes in the exact keystrokes above. When doing it for real, you see all the changes on that first line as you do them, so if something isn't quite right, just hit u to undo and keep going. It's so easy, I can record and replay new macros all the time. I almost never have to do repetitive editing.
Another trick, not available in viemu but available in vim: select a bunch of lines, then type :norm and your next editing commands after that will get applied to all the lines. For example, to add a comma to the end of every selected line, :norm A,
[+] [-] blindhippo|14 years ago|reply
Knowing Vi (or Emacs) is essential as a software developer, but using it as your local code editor has never made sense to me.
What most people who pontificated about Vi/Emacs/editor-of-choice often fail to realize is that there isn't a "One True Way To Do Things Bestest". Everyone works differently. Using Vi for 30+ hours isn't going to make me a better developer - and it certainly isn't going to speed up anything.
[+] [-] AdrianRossouw|14 years ago|reply
[+] [-] manuscreationis|14 years ago|reply
I'm trying to learn more about vi/m (and emacs) as I get more into Linux development, but I think a lifetime of Windows has damaged me, mentally
[+] [-] techiferous|14 years ago|reply
[+] [-] phlyingpenguin|14 years ago|reply
The one problem I have is that my vimrc/.vim stuff is all customized far enough that I can never use any of the vim-like emulated modes in other text editors. I think evil-mode may be possible if I wanted to learn how to configure emacs at all, but it's generally not worth the hassle. I'm not sure about the particular Visual Studio plugin that the link is to, but one of the two doesn't allow remaps, for instance. It's generally not a problem to use j/k for short periods of time at least. My big problem Dvorak wise is Nethack which is sort of a pain. I bought a Qido USB layout switcher to make games like that possible.
[+] [-] nik_0_0|14 years ago|reply
[+] [-] mmavnn|14 years ago|reply
[+] [-] un1xl0ser|14 years ago|reply
Then you learn all the meta-commands. All of these building blocks are only limited by your creativity of combining them to get what you want done. The more commands and tricks you know, the more you can slice and dice text, code, logs, whatever inside your editor (without leaving it).
I guess it's just a Unix/neckbeard thing. This is how the rest of Unix is designed, so why not the editor.
[+] [-] Aga|14 years ago|reply
Later I have recommended this article to others of whom some have had similar experiences...
The author does a fine job describing the vim-philosophy instead of just a bag of tricks.