Isn't this just because he is more experienced in Vim? I'm not an expert in any case, but is it really true that Vim is that much faster (editing-wise) than Emacs?
I'm guessing that everyone's editor of choice would be the one they're most comfortable in. In other words, the one in which they've invested the most time into learning.
Emacs will also help you when your in weird situation because it is so powerful. One very simple example: we had some new machines installed recently but they didn't have our home directories nfs-ed onto them because the San was in a different network. With e-shell In emacs I could copy over my files without even opening a window to my home directories because emacs's tramp mode is built into the shell. It meant that I had autocomplete in my shell while working on a remote machine. Guys were ftping files clumsily over while I just had to use "cp" and the tab key.
But sure, google a solution, download and compile it, then learn it and fix your problem...
I'll just emacs's ;)
I'd be interested to hear if anyone else has moved from emacs to vim. (Or thoughts of people who've gone the other way.)
But e.g., stuff like "." the e/E and b/B distinction, [d]f (like zap-to-char but waaay more useful) don't really have emacs equivalents.
And come on, C-f, C-b, C-n, C-p to move around -- not smart! I assume it's for "forward, backward, next, previous", but you shouldn't choose your most basic motion keys to have memorable names, you should choose them to be efficient!
While M-f, M-b are e and b, I don't know of an exact equivalent for E and B. But they could very easily be added.
IMHO, basic editing in Emacs has slightly higher constant factors (mostly due to typing the modifier keys), but scales much better as operations become more complex.
As for adding equivalents to E and B, sure, but what keys do you bind 'em to? Either unwieldy C-c FOO combinations, or spend the rest of forever playing whack-a-mole with various modes that happen to have already defined the keys you wanted to use. While emacs is infinitely customizable, the baseline editing functionality that everything expects is important -- otherwise you're just fighting against the grain. Though the various vim emulation modes have made a heroic effort...
It would be interesting if something like that vim keystroke competition could be expanded to include emacs as well. >:)
"Super"-f/b are free on my keyboard, where "super" is the button with the Windows logo on it. I don't really miss the E/B functionality, though, and I used vim for about five years before I started using Emacs.
(BTW/FWIW, I'm on mac and keep the option key as command, so no extra key lying around for me to use as super.)
I'm easily sucked into vi / emacs threads, and I've talked about this at length a few times. I have a bit over five year experience with each, at this point. I prefer vi's general keyboard interface design (edit vs insert mode, etc.), because it gets rid of most of the modal keys that Emacs uses, but strongly prefer Emacs's "continuous environment"/integration and general extensibility. On the balance, I prefer Emacs. (And while there are vi-emulation modes for Emacs, such as viper, few extensions provide vi-like keybindings for them.)
For "." you could say that C+k,C+_/C+y does most of what I want done -- and arguably, the more complex cases might be amenable to using regexp-replace.
Regretfully, the only time I ever use hjkl is to play crawl :) The emacs keys are perhaps more geared towards using modifiers, with M-f/M-b + C-f/C-b serving as the closest replacements for movement, and M-z for zap-to-char.
gin17 ~ $ time emacs --eval '(save-buffers-kill-emacs)'
gin17 ~ $ time vim --cmd :q
Well, after all this discussion, I'm probably morally obligated to spend more time with vim (or maybe vimpulse) so that I actually know what I'm talking about. :)
If only it had some way you could customize it, eh? ;)
Plus, I'm already not sure if the time I save in emacs is worth the time I lose fiddling with it ;)
The same could be said about Python.
I use Vim because it's an enormously powerful tool that makes me more efficient and because I enjoy using it. (I've never spent four hours attempting to debug my code only to discover that the problem was a bug in Vim. I can't say the same about Eclipse.)
Vim and Emacs are not toys. If you think they're toys you haven't invested enough time in them to understand how they work. Note that I'm not saying that a competent Vim/Emacs user might not prefer something else. I'm saying that you can't get to the point of being a competent Vim or Emacs user without understanding how enormously powerful both are.
Vim and Emacs can do just about everything your IDE can do (and, in many cases, more). The difference is that you're not starting with everything built in and crowding a complicated GUI. You're starting with something simple and powerful and (if you want) building it up with exactly the features you want.
As far as emacs not being everywhere, I recently just learned about mg on openbsd. If I had just rtfm I would have found it years ago.
Sorry, no. I don't have any prejudice on whatever programming language you use, but you're making yourself look like a plain dumb person, period by saying that you can't be productive with Vim or Emacs with large pieces of code.
Here's just a few notable cases...Guido and Python with Vim and Emacs, Torvalds and Linux/Git with MicroEmacs, Stroustrup and C++ with Sam, DHH and Ruby on Rails with TextMate, Matsumoto and Ruby with Emacs, Zawinski and Mozilla with Emacs, Steele and Scheme with Emacs, and on and on.
This is possibly true in Java, but in better languages you don't need much help from your editor to be productive.
vim doesn't have a debugger since it's outside the scope of vim, which is just an editor. If you want an "all-in-one" philosophy, maybe emacs will treat you better.
Now, if you're doing work in compiled languages like Java and C#, the code-completion of Visual Studio and Eclipse is very valuable. But besides that, I'd much rather have a simple and fast editor over a bloated IDE with tons of features.