There is no elephant in the room. Vim will not make you more productive, period. Vim unequivocally takes the fewest keystrokes to effect changes, but its certainly not the fastest editor. At Floobits, we sometimes have 3 devs working on the same code at the same time (normally when something goes really wrong). When ggreer is around, he is always the fastest to edit text bar none. He uses ST3 and a trackpad. If someone is using some Intellij (PyCharm, Idea), that person is the fastest and safest at refactoring bar none.
It may be true that some magical Vim invocation is the fewest key strokes in any text editor to edit text. In practice real world Vim users probably lose just as much time as they save trying to find the magical incantation. Beyond saving a few keystrokes, consider how wasteful it is to devote months of effort learning a new text editor when editing text is such a small fraction of the time we spend programming. Are programmers ever limited by how quickly we can type? No, we are limited by how quickly we can think!
Having said that, NeoVim is a fairly decent choice for a text editor. It is open source, runs in a terminal, is actively developed, and (vim) is installed on nearly every *nix by default.
Vim will not make you more productive. At [gratuitous company plug!], the
dude with Sublime is the best touch-typist, and the guy with an IDE is
good at refactoring.
These are false comparisons, and have absolutely nothing to do with Vim.
Does your Sublime guy code fast because he's an amazing touch-typist, or because he has better command over Sublime's shortcuts and special features than your Vim guys do? If it's the former, then it's irrelevant. If it's the latter, then it clashes with the point you tried to make in the next paragraph.
Of course your IDE guy is better at refactoring code. (S)he's using an IDE. That's what they do, better than any text editor. Comparing editors to full-blown IDE's is fairly "meta" to the topic at hand. However, it should be noted that almost every major IDE has built-on or plugin support for popular editor keybindings. I use Vim keybindings with IntelliJ... and even with my fairly baseline Vim familiarity, I'm able work several times more fluidly than on vanilla IntelliJ.
It may be true Vim requires the fewest key strokes to edit text. In practice,
you'll lose more time finding those ideal keystrokes. It's wasted effort to
learn a text editor, because programmers are not constrained by typing speed.
This is just outright nonsense, and tells me that you personally have never learned to use any text editor well. Sure, I would agree that it's unproductive to scour StackOverflow for a magical one-step incantation for EVERY thing you ever do. However, that is not what being proficient with Vim (or any other text editor) means. It means you organically pick up on things over time, such that you aren't having to think about it when using them.
If you pick up Drew Neil's book "Practical Vim", it's structured around 121 "tips". Each one is short, clear, and something that you can pick up and internalize in an hour. After the first 24 or so, you will absolutely be more productive that you would be with "Windows Notepad" bindings in the same situation.
It's not about crazy incantations that refactor your entire codebase in one keypress. It's about simple little things, that add up:
* I want to add an extra parameter to this method I just wrote. So rather than taking my hand off the keyboard and clicking there with my mouse (or hitting the arrow keys over and over), I just press "f)" to jump to the closing parentheses and start adding text.
* I want to replace everything on the current line, starting from my cursor position somewhere in the middle of that line. Rather than moving my hand to the mouse and dragging a selection, or holding <Shift> while hitting the arrow keys over and over, I instead just press "c$" and start adding text.
Sure, commands can be a bit arcane, but I learned them organically over a period of time... and these are real-world things that I do many times almost every single day as a coder. I probably only use 10% of Vim's available functionality, and that's enough to make my coding a much more fluid experience than it was before. Until you've experienced it first-hand, it's hard to grasp just HOW DISRUPTIVE it is to your flow and thought process to move your hand from the keyboard to mouse and back!
I don't care which editor (or IDE keybindings) you use. Vim, Emacs, Sublime, whatever. But you will absolutely be a more productive programmer if you pick one and dig into it over time. You ARE limited by your typing flow, and just don't realize it. If anyone really believes that isn't the case, then why bother to learn touch-typing? Take your two index fingers and try coding with the "hunt-and-peck" method, and see how it doesn't limit your thought process.
Since you mentioned you're using vim keybinding yourself, I thought I'd mention that any time you type x$ (where x stands for delete, change, yank, etc), it's better expressed as X[1]. You mentioned c$, but C is the same thing.
[1] - Vim actually breaks this pattern on y—Y is the same as yy out of the box. But almost every vimrc I've seen remaps Y to y$ for consistency.
If I understand, your statement that X is better than x$ is based on keystrokes.
But there are other ways to look at that.
x$ is more consistent with the general idea of verb object. If part of your memorized subset of Vim includes xiw (do x In Word), xe (do x to the End of the current word), x) (do x to the end of the current sentence), etc, then x$ fits in with that. In fact for this reason (not consciously decided), I almost never use X variants.
For me personally, there is also less wrist-twisting if I don't use X, which involves moving my pinky down to the shift key; that always feels like I'm walking up to the edge of carpal tunnel.
But bottom line, none of those and similar choices are objectively superior to the others. What matters most is how much of what you do can be done with no conscious thought, that it just happens. The best parts of vim for me are the ones I no longer know how to do, the ones that are in muscle memory and that I have to stop and think about after someone asks "how did you do that?"
From that point of view, YVSANMVSBYVSAOK[1].
[1] Your Vim Strokes Are Not My Vim Strokes But Your Vim Strokes Are OK.
Hmm, you're right. Just goes to show that I don't think much about what I do in Vim. :)
But the consistency of combining known verbs with known objects still holds. If I know a verb I can operate on any object. If I know an object (motion) I can use any operator on it.
Wow, thanks! This is exactly what I'm talking about, with organic learning over time. Just about every week, I pick up some little tidbit like this, which makes my editing flow a little bit smoother than it was the week before. I doubt that I'll ever know EVERYTHING, and that's okay.
I'm the guy kansface mentioned. I've spent a decent amount of time figuring out how to make my programming experience better.
I've tried almost every editor out there: Vim, Emacs, Sublime Text, Textmate, Visual Studio, IntelliJ, and Atom. I've customized them all with plugins. I've even written plugins for most of them. My first editor was pico, quickly followed by Vim.
My toolsmithing goes beyond editors. I've tried different keyboard layouts to improve typing speed, settling on dvorak with qwerty shortcuts. I even gave chording keyboards a shot. I built Ag[1] to search code faster.[2]
I don't own a mouse. If I want to point at something, I use a trackpad. Switching to/from it is much faster than grabbing a mouse.
People don't want to hear this, but I could not be as fast in Vim. Even if Vim had every feature in my current setup, it would still be slower because Vimscript executes synchronously. Executing plugin code blocks Vim's UI. If a plugin spawns a subprocess, the UI will be blocked until it exits.
With Vim, you can't start a search and examine another file while it's running. This problem can be worked-around by using multiple Vims or searching from the command line, but then you lose quick opening/replacing of results. You can also abuse certain AutoCmds and updatetime to get a sort-of working async execution, but it requires each plugin have its own event loop.
I agree with kansface: Vim users may type less, but they don't move faster. I have yet to see a Vim user who has impressed me with their speed. I typically see wasted motion, waiting for commands to finish, and fixing mistakes in regexes. Even your example invocations are as good or better in Sublime Text.
I want to add an extra parameter to this method I just wrote. ... I just press "f)" to jump to the closing parentheses and start adding text.
That does not jump to the end of the function definition. That does a search for ) on the current line. If your cursor isn't on the right line, you're SOL. Also, ) shows up in many places. It may not be part of a function definition in the language used. In my setup, "cmd + r, up" goes to the previous function definition no matter the language. If I want to go to the end, that's ctrl + m.
I want to replace everything on the current line, starting from my cursor position somewhere in the middle of that line. ... I instead just press "c$" and start adding text.
For me, that's ctrl + shift + e, (start typing). Unless you have a $ key, both are three keystrokes.
If you use Vim and you're happy with it, great. But I would heavily discourage anyone from switching to Vim. Editors and UIs have come a long way in the past 25 years. Even with nerdtree, YCM, and other plugins, Vim can't catch up. NeoVim looks promising, since it fixes Vim's architectural problems.
I understand that your company butted heads with the Vim maintainers last year (as discussed elsewhere in this comment thread), and that an asynchronous plugin architecture would be super-helpful to your company's integration needs.
However, if you are announcing with a straight face that Vim slows you down because of synchronous regex scans, then that is flatly ridiculous. Are you editing terabyte-sized source files? Because if so, then perhaps some refactoring is in order (get the PyCharm guy to do it)! My mind is boggled by the number of plugins one would need to install in any text editor for the difference between synchronous and asynchronous execution to even be perceptible on a contemporary laptop with a typical file.
I mean, if you are happy with your text editor of choice, then godspeed and enjoy ("editor wars" are always a bit tongue-in-cheek). However, if you're adding a slew of IDE-like plugins to Vim (especially a pig like NERDtree), then beyond a certain point it makes more sense to just install the JetBrains product relevant to your language, and use whatever keybindings you like from within that.
The way you guys all keep plugging NeoVim (which doesn't even have an alpha release yet) definitely smells fishy, a transparent axe to grind. The Vim guys didn't want your patch. Sorry.
I point out an architectural shortcoming, explain how it affects me, and you say the real problem is that I have too many plugins, the files I edit are too big, or my computer is too slow? Whose mind is boggled now?
The way you guys all keep plugging NeoVim (which doesn't even have an alpha release yet) definitely smells fishy. The Vim guys didn't want your patch. Sorry.
There's nothing fishy about our support for NeoVim. We don't know the authors (though I, personally, did throw some money at the Bountysource). There are a few reasons why we like them:
1. They share our pain. Thiago de Arruda (main author of NeoVim) tried to add a similar patch to Vim. Like us, he spent months trying to work with the Vim community before being rejected.[1]
2. We like NeoVim's architecture. If we had infinite time, we'd be writing a very similar editor.
3. NeoVim makes our product better for Vim users. They get the UI they love, but without a broken leaderkey or other annoyances.
While the readme says it's alpha-quality, it works fine. It can be used with current Vim plugins and performs better than Vim.
The "effect" that you described was being unable to work at a normal speed, because you browse directories faster than NERDtree can display them. Because you can't start a text search in a background thread, and work with other files while that's running. Etc.
You know, about once or twice per day I have to do a text search through a 750,000-line codebase. IntelliJ blocks also, but it completes in 3 to 4 seconds... and Vim searches a hell of lot faster than IntelliJ. In two decades of working with vi/Vim, I've only experienced UI sluggishness when working with log files that were each hundreds of megs in size.
So to be clear, when I suggested that you might use too many plugins, that was sarcasm. To be even more clear, I was flatly calling you a liar about your original premise.
Synchronous vs. asynchronous plugin execution is not an "architectural shortcoming". It's an "architectural decision". An architectural shortcoming is something that two separate submitters can't each resolve with a single patch. Right or wrong, the Vim maintainers were given the option... and apparently made the conscious decision that the benefits of asynchronous plugin execution aren't worth the risk of plugin authors doing dumb things with it.
I do wish that they had been more forthcoming with your company in how they did (or didn't) convey that decision, but ultimately it's their call. Creating or supporting a fork is likewise your call. But at least be honest about the agenda. You guys take an active interest in criticizing Vim, and promoting NeoVim, because the Vim maintainers rejected a patch that would help your startup company integrate with them. Not because the syntax highlighter can't keep up with your Warp 9 typing.
It may be true that some magical Vim invocation is the fewest key strokes in any text editor to edit text. In practice real world Vim users probably lose just as much time as they save trying to find the magical incantation. Beyond saving a few keystrokes, consider how wasteful it is to devote months of effort learning a new text editor when editing text is such a small fraction of the time we spend programming. Are programmers ever limited by how quickly we can type? No, we are limited by how quickly we can think!
Having said that, NeoVim is a fairly decent choice for a text editor. It is open source, runs in a terminal, is actively developed, and (vim) is installed on nearly every *nix by default.