But it's not. In a modern editor, swapping two lines is ctrl-shift-up for swapping up, or ctrl-shift-down for swapping down.
Vim isn't that much more powerful any more compared to modern code editors, it's just weirder.
> I've known Notepad++ users who were faster Ruby programmers than me--I could certainly edit faster with vim
So were you a faster typer? How was it faster?
I find there's two points that get me speed in a code editor: Language specific shortcuts (like go to definition) and multi-cursor editing for editing formulas and the like.
But I'm not sure if Notepad++ has multi-cursor.
I'm not sure if vim does, either? I know you can do stuff whose result is very similar to as if you were multi-cursor editing, but do you actually get intuitive methods to place multiple cursors in various ways and then interactively edit what's there while seeing it change?
Because that's no longer a "nice to have". There's a huge difference between formulating an incantation in your head firing, and seeing if the result is right--that gets really complex with multiple edit points--and doing it interactively. You actually see a block of code grow and unfold interactively as you edit it. And it doesnt involve regular expressions :) (which are cool, but almost never fail to take my mind completely off the problem at hand, I only benefit if it operates on a pretty large chunk of text)
Sure, if you really hate your hands. ;)
> So were you a faster typer? How was it faster?
Maybe I just was a faster typist. I don't know. It doesn't really matter to the point: if your text editor gets out of the way enough that text editing isn't your bottleneck, then all time spent optimizing your text editor usage is completely wasted. My argument isn't "vim is better than Notepad++", my argument is "vim in the default configuration is good enough to not be a bottleneck". Notepad++ may be good enough to not be a bottleneck either--I haven't used it enough to have an opinion.
> Language specific shortcuts (like go to definition)
I would argue that this is more of an IDE feature than a text editor feature.
> multi-cursor editing for editing formulas and the like.
I'm not sure what you mean here. There's two things I do in vim which might be what you're talking about: splits so I can be in two parts of the same file at once, or splits where I have a REPL open and am editing fragments in one half of the screen while running them in the other half of the screen. But if you're talking about something else, I'd like to understand it so I can learn how to do it in vim. ;)
Like all rules, this has exceptions. This is sort of a good "exception that proves the rule". Yes, PEP8 compliant Python development requires you make a few-line change to your .vimrc. My .vimrc contains this:
" Set tabs to width 2.
filetype plugin indent on
set shiftwidth=2
set softtabstop=2
set tabstop=2
set expandtab
" language-specific settings: tab width is 4 for python
autocmd FileType python setlocal shiftwidth=4 softtabstop=4 tabstop=4
There are two assumptions I think you're making here:
Assumption 1: You can do better than the defaults enough to justify the costs of optimizing. I use a pretty much default vim configuration as my primary development environment, and see zero evidence that this hampers my productivity in any way.
Built-in file searches are good enough for open files, and grep/git grep do well enough for other files.
Linting should be part of your build process. There's a benefit to it being a bit painful for linting to fail, because that negative reinforcement causes you learn the linting rules and start writing pre-linted code.
You might disagree with me that these benefits are minor, but that's only looking at the benefits: let's look at the costs of "optimization":
First, there's the bugs in plugins and bad interactions between plugins. Very few plugins are written to any sort of reasonable QA standard. I've pair programmed with a lot of devs who use highly custom vims, and without fail, they've got bugs in their configurations that are far more distracting and impeding than any minor inefficiencies in the default configuration. Say what you want about the default configurations, but I've not found any bugs in them in years of using them.
There's also simply the time spent configuring. At one time in my life, I spent hours trying to get things just right in my configs. The results were pretty mixed--a lot of times I ended up not liking the changes I had made and reverting them.
There's a bit of hubris involved in believing you can do better than the defaults. Instead of looking at the settings as the problem, consider the possibility that your knowledge is the problem. It's likely that there's a good enough way to solve your problem in the defaults, and you simply don't know or grok it yet.
When I first started learning vim, I thought it was kind of stupid--everything seemed way harder than it needed to be. But once I actually grokked the tool, I realized that my initial impressions were the stupid ones. A lot of problems I've run into over the years with vim are like that--the problem wasn't that the default vim didn't solve my problem, it was that I didn't grok the solution which was easily assemble-able from the vim skills I already had.
A programmer I really respect has a background process which watches file edits, internet usage, and a few other things (i.e. VLC) and automatically tracks his productivity. His process marks time spent editing Emacs configuration as wasted time, and I agree. Although that might be because it's Emacs configs rather than Vim configs. ;)
Assumption 2: Text entry is a significant bottleneck compared to other areas of your process. In backpacking, there's a saying, "Don't save ounces when you can save pounds." The idea is, don't optimize the weight of your lightest things, i.e. your stove and water bottle, when there are still big optimizations to be made on your heavier stuff, i.e. your big three (backpack, sleeping bag, tent). Configuring your editor is almost always an attempt to save milligrams.
Frankly, once you reach a certain proficiency with an editor that's automatic enough to just get out of your way, editing becomes a subconscious process, and you can be thinking about other things while you edit. I think some people believe that they think of what to write, and then edit it in, and any slowness in editing is preventing them from thinking of what to write after that. I don't think that's how the brain works--if you don't have to think about editing, then you don't have to finish editing to be thinking about the next thing. So the best thing your editor can do for you is to not make you think about it consciously. The more complicated you make your editor, the less likely this is to happen. The power of vim is that it lowers a lot of more complex edits to the subconscious level: swapping two lines is three keystrokes, so it's a simple enough process that I don't have to think about it.
Once you reach a certain level of subconscious-ness with an editor, editing simply isn't the bottleneck. I've known Notepad++ users who were faster Ruby programmers than me--I could certainly edit faster with vim, but they could come up with the solution to the problem in their head faster because they're more proficient with idiomatic Ruby. If editing really is the bottleneck, the problems you're solving are quite easy for you, and you could probably get paid a lot more if you took on harder problems!
And that's just looking at the process of implementing features! There's a lot more to software development. I've yet to work at a workplace where requirements gathering and keeping shareholders informed weren't much larger opportunities for optimization than my editor configuration.