(In the following, I will use “vi” to refer to vi-like editors in
general, including Vim. I will also use “Emacs” to refer to EMACS-like
editors, including GNU Emacs.)
Interesting . . . right away, when the question was first asked, several
vi users responded. A day later, I find that several Emacs users
responded as well. I can only surmise that the vi users responded more
quickly because vi helps people get things done more quickly.
No, no, I’m kidding. It was probably actually a result of Emacs’ slow
No, wait, I’m kidding about that too. The truth of the matter is that
both of these editors have some serious learning curves associated with
them. See the image illustrating those learning curves on this page:
Vim for New Users http://sob.apotheon.org/?p=981
In terms of what they provide to the person who scales that learning
curve, becoming an adept user of either one of these editors, the return
on investment is incredible. Each has its advantages over the other, of
course, and which you will prefer is a matter of preference more than
anything else, it seems – though of course we (heavy vi and Emacs
are probably all afflicted by the sincere belief that one of them is
objectively superior to the other. It is taking a powerful act of will
to avoid turning this email into a platform for extolling the virtues of
the vi way of doing things. I really do not want to be accused of
starting a flamewar with a partisan attack in this email.
Ultimately, however, my thought is that if you are already comfortable
with either vi or Emacs, you should use it anywhere that it is at all
reasonable to do so. While other editors may provide some handy
that make them particularly useful in certain contexts, such as
for Ruby development, those features’ payoff is limited – and it goes
away the moment you start working on a different task.
The payoff for using the vi or Emacs way of doing things applies in
almost every single situation where entering or altering text is the
task at hand.
The benefits of these editors are not limited to context-specific
features like those of Visual Studio (or whatever); they grow
endlessly over time, as you learn more about how to use them, tweak
them to suit your personal preferences, and acquire the knack of
applying them effectively in more situations.
They are everywhere, while other choices like TextMate are
generally much more platform-dependent.
They aren’t going anywhere. As long-established staples of open
software culture used by more people than almost any other piece of
open source software, their durability in the face of developers and
vendors getting hit by buses, going out of business, suffering
crippling RSI that prevents them from coding, or just getting bored
with them and ceasing to perform needed maintenance on them is nearly
unmatched in the world of software development. The same cannot be
said of UltraEdit’s futureproofing.
Ultimately, there probably isn’t much reason to switch editors if you
already comfortable, and gaining increasing proficiency, with vi or
Emacs. If you have never used either, though, and do a lot of coding,
you should probably give each of them enough of a try to get past the
point where you feel completely helpless, then pick the one whose
“philosophy” best suits your taste and stick with it long enough to
feeling its benefits. At that point, give it up if you don’t like it,
but if you do a lot of coding (especially in high-level dynamic
like Ruby) you will probably get to love one of these editors –
especially if you spend a lot of time in a Unix-like environment.
: The editor or IDE mentioned in this case is basically just a
placeholder for “pretty much every editor in the world that is not
vi-like or Emacs-like”.
: The editor or IDE mentioned in this case is a basically just a
placeholder for a sizable subset of the applications from note .
TextMate users in particular should not take it personally; I’m sure it
is a wonderful editor, despite its platform snobbery.
: I hear this happened to Richard Stallman, famous for his
in the early development of the original EMACS and for his ongoing
maintenance of GNU Emacs (when he wasn’t suffering crippling RSI).
Chad P. [ original content licensed OWL: http://owl.apotheon.org ]
PS: I should probably polish this lengthy ramble into an article for
TechRepublic at some point.