I've never understood the appeal of vi(m). Programming is a thoughtful, creative, deliberate process. I'm never in a situation where I've got so much to type that my productivity would drop if my fingers stopped touching the keys. Rather the opposite in fact.
Actually, if you are in 'insert' mode in Vim all the time "you're doing it wrong". Vim shines when editing and tweaking existing code. You should be in 'normal' mode almost all the time, where you do your "thoughtful, creative, deliberate process" by reading and navigating the code base, and reformatting, moving, copying and deleting code, to get it just the way you want.
If you are just doing straight-ahead typing, you're right, Vim won't help.
The book "Practical Vim" has a nice analogy with how artists work. "Pause with your brush off the page." Painters do a lot of things besides applying paint to the canvas. "The painter does not rest with a brush on the canvas. And so it is with Vim. Normal mode is the natural resting state."
I'd really like to see a usability study between Vim experts (10y+ usage) and Sublime Text 2 (1y+ usage) experts on a keyboard+good touchpad combo. We could even do it in theory by counting number of actions and assume the APM in vim to be 10% higher (which is quite optimistic).
Surely if you need to pack reformating, moving, copying and deleting code into as short a time as possible you're doing it wrong even more than if you had to insert a lot of text!
This leaves navigating as the main reason for vi's UI. And macros, apparently. If that's what you want, great, but it's not for me.
As others have said: You didn't learn touch-typing to churn out text as fast as possible. You learned it because it creates a more direct interface between brain and machine. It doesn't hinder your toughts, doesn't break the concentration.
It's the same with vim editing: The idea is not to be able to move code around as fast as possible but to do it without thinking. It's a step closer to the perfect brain-reading computer with which writing code is only a matter of imaging it.
For a new code base, you might be right. As code bases grow, so does cruft - and the older the code gets, the more it requires moving things around just so before you can add new items.
For me, it isn't typing speed that makes vim better. It is the speed at which I can make very direct and precise edits to something that I have already typed. Especially repetitive edits, where the pattern can be recorded.
When trying to hold a problem in my brain's working memory, a bad editor turns a simple change into a swap-to-disk event.
Right, it becomes automatic thought->fingers edits. So yesterday, when I was dealing with some javascript on a webpage, i had a realization that if I did some restructuring of my closures, the code would be smaller and simpler to understand. As soon as I was thinking my fingers were already setting a couple of marks, and putting various lines at various indent levels[1]. Then I thought, these need to be grouped together by indent level, and the reordering was happening, again almost background. I never once thought get rid of this line here and put it here. I thought, ok move this line down a few, move this chunk to the outer scope. Put these lines in a separate function.
Yes I could do this slower/more methodically with other editors, but I tend to think visually, so I visualize the text transforming as I think about the code. The power of vim for me is that I have a language of text transformation that can be simply translated to commands at a speed near to me thinking it.
Much like when typing documents, words in head -> text on screen doesn't involve a lot of "and now i press 'a', now i press 'b'".
[1] at one point this would have been a conscious decision, but since I try to maintain consistent indenting to help define scopes, and since vim has a lot of good indent/unindent commands, I had a realization that this could help refactoring. After some practice it became automatic since its a simple << or >> in normal mode to change indent level. Now it has become a wired pathway in my head, so I just think, "oh this goes up a scope" and the actual steps of "so dedent which means press <<" never registers.
This is something to aspire to (for me). I rely on a core subset of vim commands far too often, and need to expand my vim vocabulary. It's a matter of investment in one of my most important tools. Unfortunately I'll probably need to do it a few times so it sticks, or review everything but only focus on integrating into my daily routine a subset of that each time so there's a chance it sticks.
Every 3-6 months I review my understanding of VIM, browse the help manual, browse the vim tips site, and browse the vim subreddit. I find a few things I don't know but actually look useful to me, and queue them up for workflow integration.
Then I pick one for a week. I consciously keep it in mind, and when I notice I didn't use it, I undo and force myself to do the other way. Eventually it's enough to get the habit. So I move on. Repeat until the queue is empty. Then let all those things settle in for a while and after a few months, go to the top.
The other thing I forced myself to do is: become aware of random frustrations or annoyances when using Vim. The question "is there an easier way to do this?" has a disproportionately high nubmer of "yes" answers, so I track down then and there how to do it better. The reasoning is that - if I'm getting annoyed, it's because I keep having to do something, so right now is a good time to learn the solution while I have a bunch of practice available in my normal working day. The trick is to realize that it's like writing a script: i'll put some time in up front right now, but the work will overall get done faster, and the long tail of future improvements will add up to huge gains.
The final thing to note: I regularly rediscover Vim features. Like you mention, stuff just slips out sometimes, it's no big deal. My current workflow and common command set is different than it was a year, or 2 or 3 years ago. Some things I'm sure I'm less efficient with, and other more. But overall the trend is towards more proficiency and better usage, so it's OK that stuff comes and goes from my awareness :)
Do you understand the appeal of touch typing over hunting and pecking?
Touch typing is hard at first. You have to force yourself to learn it. But once you do, you don't have to think about typing anymore. Isn't learning to touch type liberating to your productivity and thought process?
Touch typing is a great skill to have of course, as is using keyboard shortcuts. But I can get by with standardised shortcuts, and I'd prefer not learning a new set of shortcuts used by a single program, especially when that program has a modal interface. Maybe modal keyboard interfaces are used by more than vi, but I don't know of any other programs that have one.
So what other programs do you use that have a balance parens command? or shift text left or right? Beyond the basic movements, all your "interesting" shortcuts are specific to your text editor anyway.
Unless you're using emacs on a Mac, in which case you have emacs keybindings in all the standard text fields anyway.
Or if you're using MacVim, which supports the standard mac cursor movements (command-arrow to end of line, option-arrow to move by word, option-delete to delete word, etc)
Once I fell in love with modal editing, I started using it everywhere I could. vi(m) bindings in my shell, web browser, etc. I wish it were seamless everywhere but it's certainly more ubiquitous than just one program. Couple that with a working knowledge of emacs navigation keys which work throughout OSX and thing become a lot nicer.
Having to touch the mouse while just editing text slows me down and breaks my rhythm.
My standard vim configuration is this:
set ts=3 "I like a tab space of 3
map <F5> :set hls!<bar>set hls?<CR> "Turn text search highlight on/off with F5 key
You can add more stuff, but the basic functionality I use everyday is just there. It takes me the actual time to install vim (if it's missing) and plug in those 2 lines and I'm ready to edit.
Using buffers comes and goes for me, I'm not a vim power user, I usually cut/paste blocks of text by checking the line numbers and doing :<start#>,<end#>y to copy, and p to paste. I learned to edit back in the day using a modified version of ed on a MUD, so my approach probably
isn't the norm, but it's always worked for me. Adding
Cscope as a backend pretty much makes it do everything Eclipse can do, only faster.
I usually am not adding tons of text at once, more usually I have my window split (:split <filename>) between a couple
of source files pondering what is broken/working/needs to be added.
However, someone starting out can make more sense of one of the Wysiwyg editors, vim and the like (emacs comes to mind obviously), require a little more time to make productive. Once you have enough arcane incantations, the thought of doing something and the action happen almost instantly, and it's very, very, very hard to go back to having to interact with a mouse-based editor (I still use my mouse for copy/paste in some situations, though, so I suppose it's not as big a deal as I feel like it is).
seems like instead of copy and pasting like that you would be better served pressing V and using some form of block navigation.([,(,{, etc.) see :help text-objects for more examples. or a search would work as well for some queries. /textToFind then enter and then navigate to fine tune your selection if it's off by a bit.
Right, the line number is mostly just my habit. Occasionally I'll just yank with a regex, ie: y/<regex>, but that usually requires stopping to think.
I guess my point is there are a lot of ways to do things in vim, and even just learning a couple of them is in general quite powerful. Additionally, being able to use regex's with commands is very useful, and something not readily apparent if you aren't much of a regex user.
The line number thing is generally a search to first line (line number is in the ruler at the bottom of my vim window), search forward to last line, execute command. I suppose this is actually an ed-compatible command, older than vi.
I think people overestimate how much time they spend doing repetitive tasks like copying and pasting with definable patterns. I'm a Java programmer, and I certainly do this, but I can almost always use a simple search and replace to make it work in IntelliJ. But, for the sake of argument, let's say that if I were to do this once a week, maybe for five minutes, copying and pasting manually with a mouse, that five minutes might feel like an eternity. Vim would do this quickly, but it would also slow me down when I do project-level refactoring, like renaming a method, which IntelliJ does globally in a matter of seconds. Sure, you can configure Vim to do this kind of stuff, and you can combine it with other tools... but at what point are you getting diminishing returns?
On top of it, as a web developer, I already need to know so much, from front end with HTML, CSS, JavaScript, jQuery, to Servlets and Spring MVC, to SQL and all of the glue that binds all of this mess together like XML and supporting tools like SCMs. My head is absolutely full of information. In this environment, I am convinced that Vim is a complete waste of my time. A good IDE is ten times better at handling the vast majority of tasks I encounter day-to-day.
If anything, I think Vim is like truck nutz for programmers. It's all about projecting an image of competence and bravado.
I agree with parts of your comment, except for two extremely erroneous phrases. «My head is absolutely full of information.» and «...Vim is like truck nutz for programmers...»
- If your head is absolutely full, do yourself a favour and stop working in IT. Go do something else. There is now other way to put it.
- Go watch someone proficient in vim at work. You'll lose that image of truck nutz you have.
I do consider vim the wrong tool for the job of editing Java code. Refactoring with Eclipse (in my case) is wonderfully powerful and something impossible to achieve with vim. HTML/CSS/Javascript/XML/most everything else? VIM. Absolutely.
Even with the wonders of Eclipse refactoring tools, I do miss vim many times. VIM is like the command line of text editors: lots of small tools, with incredible combinations.
As for the bravado, everyone knows real programmers program using butterflies: http://xkcd.com/378/
A few examples of why vim has some non-obvious power:
* html you can change inside of a text object. If you are say anywhere inside of a link <a href="som|e link"> you can ci< and you have deleted the whole thing and are left with <|> (where the cursor is denoted by |) If instead you typed ci" you would be left with <a href="|"> this is a very powerful pattern
* you can script little macros that do text editing on a macro scale very efficiently. This is more useful than a simple find and replace.
you want to make a list that starts with a number, has that number in it and is incremented by one(or two or...) every time.
Type the first sentence
1, xv001, "", more stuff.
exit out of insert mode. jj or esc
start recording the macro into register r: qr
yank the line and paste it yyp
go to the beginning of the line 0 or ^
increment by one and move one word right and increment the next number: ctrl-a w ctrl-a
move down one line, j
exit recording q
run macro r 100 times 100@r
The nice thing is that if you mess something up you can paste whatever is in register r, edit it, yank it back into register r and run it. It sounds like it's slow but it's all real time editing and you are doing it interactive so you don't have to do it blind.
There are many more things that make vim style interactions a boon to your productivity but I don't have a lot of time to comment on it. hopefully I touched on enough that it piques your interest to at least give it a shot.
Vim is so popular that you can get pretty good emulation in a lot of IDEs so you can have the best of both worlds. vimemu for Visual studio is supposed to be very good. eclipse has eclim, hell even emacs has evil mode.
Well the formatting got messed up and it's too late to edit it:
* html you can change inside of a text object. If you are say anywhere inside of a link <a href="som|e link"> you can ci< and you have deleted the whole thing and are left with <|> (where the cursor is denoted by |) If instead you typed ci" you would be left with <a href="|"> this is a very powerful pattern
* you can script little macros that do text editing on a macro scale very efficiently. This is more useful than a simple find and replace. you want to make a list that starts with a number, has that number in it and is incremented by one(or two or...) every time.
Type the first sentence 1, xv001, "", more stuff.
exit out of insert mode: jj or esc
start recording the macro into register r: qr
yank the line and paste it: yyp
go to the beginning of the line: 0 or ^
increment by one and move one word right and increment the next number: ctrl-a w ctrl-a
Java is not a language I program in. I have used it in the past in its typical environ: over-engineered, over-abstracted monstrosities and during that time I indeed had to refactor a piece of code a couple of times.
Currently I work in C++, Python, JavaScript and Common Lisp. Auto-completion is pretty OK and the need to refactor comes up, well... never. Note that these two features are brought up the most when people want to praise the advantages of IDEs over powerful text editors like Vim and Emacs.
(Actually, Emacs' default Common Lisp environment is unsurpassed by modern day IDEs.)
One gains so much editing power in manipulating text objects and navigating through code by using Vim (well, Vim emulation in Emacs in my case) that I gladly trade in the ability to effeciently refactor enterprise-level Java or C++ code.
Even in a non-Vim text editor, I dislike moving my hands off the keyboard. It's not a productivity thing for me; it's a preference thing. As a web dev (and I hate that most of the interactivity I have to program is mouse-based), I prefer to bring up the dev tools using the keyboard shortcut, and then another shortcut to focus the command line.
I make it a point to stay relatively vanilla on my web browsers, because it helps keep my experience roughly the same as those of my users. If I ever stop developing professionally for the web, I probably will check Vimium out. :)
I've never understood it either apart from the initial euphoria of it being "something that hardcore Linux fans use". I'm not dissing it either. We should use any editor that we are comfortable with, if it's vim or something else. If your code sucks, it'll suck equally on vim or any other editor.
I can only say that when I'm using a keys-and-arrows editor like Notepad, I can barely think because I'm typing - a - key - at - a - time, but when I'm using vim I'm just thinking and seeing my thoughts.
For me it's the little things. I use the keyboard constantly to move around my code. I switched to SublimeText2 for a couple of days and the 1 second of added time it took to move my hand to the mouse to move around or use a gui interaction really slowed me down. It really surprised me how that little bit of time was just enough to break my flow. So when I say vim makes me faster, I mean that it itself is fast enough to keep up with my train of thought.
