verbs like ci" (change inside ") which deletes inside the current double quotes and leaves you in insert mode are pretty easy to get used to. dd deletes a line and puts it into the yank register so you can paste it somewhere. u undos an action.
using a plugin with visual studio is pretty king to get the best of the IDE and the most common vim functionality.
Classic SO answer on why vi: http://stackoverflow.com/a/1220118/1772636
edit: here is another classic why vi answer that is a bit different http://www.viemu.com/a-why-vi-vim.html
Humans have this funny thing as they grow older - they look at a thing, maybe try it out for few seconds, and then immediately determine it's too difficult and it will take forever. They rarely bother to spend actual five minutes, to the clock. If they did, they might actually have learned something.
25 minutes of deliberate practice - a single Pomodoro - is enough to become acquainted with several of Emacs features - like, navigation by semantic units and incremental search and autocompletion. You won't get proficient in that time, but it's enough to rewire yourself to actually start using it when writing code. Which will then lead to you becoming proficient while doing your regular, billable work.
Seriously, set up a Pomodoro timer, sit in front of Vim or Emacs, and try to practice a few things. You'll be surprised how fast you can learn.
(And yes, I did that, so I'm not talking out of my ass. I actually almost doubled my Emacs productivity once in 5 pomodoros - in 2.5 hours - two of which I spent watching Emacs Rocks videos, two on rewriting s-expressions with Paredit, and one on multiple-cursors.)
To reach a level of skill where using emacs is easier/faster/better than something like intelli-j (for instance) requires significant dedication and repetition.
Far, far more than "a few hours".
Not the parent, but I've spent a significant amount of time with pure vim. I use vim bindings in everything from my web browser (vimium, vimperator) to my WM (i3 & kde vim navigation bindings), to my text editors & IDEs (atom, VS, sublime)
Despite all that, I still find using pure vim to be ineffective relative to just using Atom, Sublime, VS or whatever with vim bindings. I may have internalized the most basic navigational concepts, but the more advanced / esoteric shortcuts that are essential to use vim as an exclusive editor are still ones I need to look up - and that's not counting stuff specific to vim packages liked nerdtree.
At the end of the day I'm sure you could always argue that I should have practiced differently / better / more or whatever - but to what end? There are plenty of full featured text editors on all platforms that do everything I need. Why on earth should anyone force themselves through dedicated practice just to learn the intricacies of a 20 year old editor?
Not parent but I have. I still would recommend something else for all the stuff I work with.
That said, it is amazing, I just believe in my line of work people are better off spending time learning an ide, esp refactoring, efficient search/ replace as well as how to enable block selection.
I sometimes do to. In particular, when that stuff is Java or C# - it's hard to beat the support IDEs gives you there. So I personally opt to switching said IDEs to Emacs keybindings instead.
(Also, one could argue that you need IDEs there mostly as crutches to support the weak language, but that's a topic for another day...)
> better off spending time learning an ide, esp refactoring, efficient search/ replace as well as how to enable block selection.
Refactoring - if you mean semantic transformations supported by your IDE, then yes. See above. But for search/replace and block selection no IDE beats the convenience of Vim and Emacs. They simply can do that better and more naturally (along with plethora of similar things helping with selection and navigation). And this is exactly the type of thing I was talking about in my previous comments - you can learn both under one Pomodoro if you focus solely on it, and then normal work will quickly take you to proficiency.
Nerdvana.
For example, do productive programmers tend to use Vim or is it the other way around? It's hard to find the causality.
I really don't think that's what's behind my attitude toward code editors, though. I've been writing code for thirty-odd years and making a living at it for twenty-five, and I've spent the majority of that time working on dev tools. Compilers, mostly - but I've written a couple of editors, too, plus a debugger, a couple of linkers, an assembler, you name it. So I have had a lot of time to think about tools, and have been lucky enough to get several chances to put my ideas into practice.
I'd have trouble remembering the names of all the different editors and IDEs I've used over the years. Emacs and vi are ubiquitous now but that was certainly not always true, and on some platforms, particularly embedded environments, using anything but the officially-blessed toolchain can make your life unnecessarily difficult. I have learned to get my work done using whatever tools happen to be on hand. That's meant a wide variation in the kinds of features which are available, the specific control-key bindings, the details of the build environment, pretty much anything you can imagine - so I have learned to rely on the basics and ignore the rest.
I find it far more frustrating to deal with a sophisticated tool that isn't working quite right than a simple, brainless tool that does the job but requires a little extra manual labor.
I'm not here to play with editors, after all, I'm here to build software, and the editors are just a means to that end. Time spent learning sophisticated editor features has to justify itself in time reliably saved using those features, which has to be balanced against the time wasted when they don't work quite right or when you have to go dig through the documentation to remember how to use them, times some distraction multiplier for the fact that you're thinking about the tool instead of the job you're using the tool to do. In my experience, there's been too much change and not enough actual need for sophisticated editor features to justify their cost.
Even if a sophisticated editor could allow me to perform certain editing tasks more quickly, that wouldn't change my overall productivity very much at all, because I spend far more time reading and thinking than I spend typing or editing. I type fast enough already; it's my brain that needs to be accelerated, and the best way I've found to do that is to eliminate distractions and focus as much as possible on the problem I am actually trying to solve.
I wrote a simple terminal-based editor a couple of years ago, including all the features I use every day and none that I don't, and I've been using it for all my daily programming work ever since. It's an unabashedly personal expression of my own taste, so I wouldn't necessarily recommend it to anyone else, but I like it and feel good when I use it. It's nice to know everything there is to know about the tool, so that I never have to think about it or try to remember how it works. Perhaps some day I'll be working in some new environment with some new toolchain and I won't be able to take ozette[1] along with me, but that's fine - wherever I go, I'll be able to get my work done with the tools I find there, because I'm comfortable doing my job with the basics.
I was thinking more of the sorts of automatic refactoring tools some people really like to use in their IDEs. I haven't found that such tools save enough time to be worth learning how to use them.
Very few programming workflows are so complicated that it is simply not possible to do something without first creating your own highly customized environment within Emacs. However, very, very many programmers do have a lot more fun screwing around with customizing their work environment (editor, window manager, shell, etc.) than using that environment to get actual work done (myself included).
Which is not to say that Vim and Emacs aren't awesome tools, I just wouldn't generalize anything about anyone based on the tools they use.
You will see that after you learn how to use Vim you won't want to use anything else to edit text, you emails, browser and word processing will be in Vim.
You only think that because you have used it and became accustomed to vstudio. As someone who has used vstudio, eclipse, atom, intellij, vim, emacs - I can safely say that vim and emacs are far more 'developer-friendly' than the others.
The sole concept of IDEs specialized for one language makes me cringe.
I still use Vim a lot, for JavaScript, for text, for remote sessions... But when a tool with real semantic highlighting and understanding of code is available (with a Vim plugin) then I'll take that.
Of course an IDE like QT Creator does many things better. But it's a tradeoff always.
Can you explain this a bit? I don't see that Sublime, VS Code, Atom, etc. were made for one language, at all. As a little background, I've used vim for a while, then switched to Sublime Text, and am just trying VS Code. I find Sublime/VS Code/Atom to be far easier to customize than vim.
I was indeed referring to Eclipse and Visual Studio. From what I observed around me, for some reason, people don't use these to edit:
- shellscripts/perlscripts/batchfiles.
- Files written in a in-house domain-specific language.
- Configuration files.
- Makefiles and project files: vcxproj, sln ...
Actually, I observed that these kind of IDEs discouraged people doing the above things, giving them the impression that it's not "real development" (I suspect that this is, in part, where the bizarre term "scripting language" comes from, but this is another debate).
TBH, not every developer is willing to become a power user or interested to learn an IDE instead of the language itself. Being someone who worked on VStudio alot and now on Linux/Mac based tools, I can safely say that Microsoft tools are Developers friendly most of the time. It's good they are introducing same touch for Linux/OSX community.