I've never learned to use vi or Emacs yet people do use them still, despite there being other editors out there that are free and useful. What is it about these two and any others like them that means they hold appeal in the face of the newer editors?


Up to this day, many environments simply have no other tools installed by default -- no X, no Pico, just plain old vi. Most people are just too lazy to change the default configurations, so I guess we're stuck with vi...

Dmitry Shechtman
vi and ed are the only editors required by posix.
Justin Smith
+62  A: 

Well, the fact that they are quite old means that:

  • there are lots of resources available;
  • lots of tools (scripts, plugins,...) have been developed for them;
  • more people have had the chance to get exposed to them.

If you work in Unix-like environments, you can be pretty sure that a variant of one of these will be available on every machine you'll see. Also, having a text editor which has a pure text mode can be quite helpful when working remotely on a machine from a simple terminal.

Personally, I tend to use Vim as I love the fact that it has a 'command mode' (this makes commands much shorter, hence easier to remember and type in my opinion), and that (like Emacs) it is (freely) available for virtually every platform.

The Single Unix Specification actually includes vi. So, even if you don't use vi full-time, its worth knowing as its guaranteed to be on any Unix system you touch (any system that conforms to the SUS that is...)

I never used Emacs, but I think people stick to vi because once you get the hang of it, it's very powerful and it speeds up many tasks.

+3  A: 

I do use gVim on my Windows machines too. I like the window handling, the diff and HEX capabilities, the regular expression search and replace.

If you want to find a decent text editor that is capable of all things that vi can do, you have to go a long way and maybe buy a commercial product. And you probably have no alternative on Unix machines. That's the biggest plus in my opinion: you can use those editors on almost every architecture with almost every OS. Can't beat that with TextMate or other (good) editors.

+12  A: 

Every feature in every new text editor out there, be it Pico, TextPad, Notepad++, whatever-the-newest-fad-is, you can rest asure that it is very certainly already implemented in either vi or Emacs, either by design from the start, or by some user who have released some script.

Syntax highlighting, carrets, code-snippets, some-kind of IntelliSense (even though Visual Studio and Eclipse do have better, but then again, those aren't text editors but IDEs), scripting, compiling, testing, you name it.

The only issue is that both programs, because of their completeness, have a very steep learning curve, which could scare off people.

Mats Fredriksson
amen to the steep learning curve! that is the main reason i avoid either.
+2  A: 

vi was the first proper editor I used, ever (in 1982 or so). I went for several years without using vi, but got back into using it full-time about 10 years ago (wow, that long). Now I use Vim as my editor of choice in all contexts.

I use Vim because it's efficient, I know many of the most useful commands (I won't claim to know them all!), and it feels comfortable. I don't know whether that really answers your question or not.

Greg Hewgill
+3  A: 

Uhh, I had a good answer for this somewhere, but it seems the entire question was deleted? (It was about IDE's vs text editors). Short version is that you can do whatever you want with Vim and Emacs, they have absolutely no limits. There are scripts and tools available for almost everything you would want to do, and if not; you are a programmer, you can make it yourself. The advantage for people like us to have full control over our tools is HUGE, and the GPL makes sure that it will never be taken away from us.

Next time edit your answer in a text editor first :)
+2  A: 

Sometimes you might log into a Linux or Unix based machine with very little resources available in the machine, e.g. embedded systems. When you want to edit a configuration file in the machine you need to use the editor that is installed. If you're lucky there might be Emacs. But if you are out of luck like me, ending up to use vi, you might run into the situation where you don't know how to exit it (the usual Ctrl-z, Ctrl-d or Esc does not work).

I found out that my close encounter situations with vi only requires the use of three commands. You type them in as you start up an editor with vi <filename>.


Insert mode, this is when you can type stuff in as a wysiwyg.


This is how you exit the insert mode.


Exit and save (don't forget to type the colon)


Exit without saving

Personally I really don't like to use vi, it is an atrocity compared to user friendly editors such as pico or nano. But it works for its limited setting.

hey, you copy-pasted that command summary straight out of my brain! That's *exactly* all i know about vi. Yes, a life-saver when needing to fix something over ssh.
You really have no idea what you are missing.
Like the church of emacs says: "**Escape** that **:** thing, **q**uit and do **!** **return**".
I used to feel this way. One day I ranted about it until there was no rant left, and then I got a visual cheatsheet that has a colour-coded keyboard on it and learned the basic commands/operators/motions. It took a couple of hours. I felt awesome because a) I learned a better way to edit text; b) I overcame my prejudices that were based on annoyance at my own ignorance. A couple of weeks later I was scarcely able to believe that I had at one point thought that nano was better in some way.
Since I've written this answer years ago I have to say that I'm still not using vi and emacs regularly. There are better editors that have code refactoring support. Common refactorings done in such tools are very effective, so why do I need to spend hours in doing them manually? Now IDEs do have features that emacs has, anyone who denies this just don't bother to set the IDE's keymapping to emacs. :P
+5  A: 

I've been using vi and Vim for over twenty years and though I've ocassionally used Emacs I keep coming back to vi and Vim.

For me one of the big advantages of vi is that, as pointed out above, it comes with a vanilla Unix install.

Secondly, once you start being able to use vi, you can translate those commands into ex commands. ex is the editor you have to use when you have serious problems. The ex suite of commands ar pretty much those that you enter when you are at the : (semi-colon) command prompt. That lovely PC tool Edlin is based on ex.

Thirdly, a lot of tools use the same command keys as vi for their own command keys.

Vim is definitely the editor of choice. Thanks Bram.

Emacs? Eighty Megs And Constantly Swapping (-:

Rob Wells
+9  A: 

I think the absolute biggest reason is momentum and the next biggest reason (and the more interesting one) is that people that are really good with vi/Emacs can usually run circles around almost anyone else in almost any other editor. The inherent design of both editors provides an awful lot of power to those that are willing to put in the time to master it.

+5  A: 

Because they're incredibly powerful. Steve Yegge puts it quite well in this article:

"Emacs is the world's best text editor. It's not just the best for editing program source; it's the best for any kind of text-editing. Mastering Emacs will make you more effective at writing and editing email, documentation drafts, blogs, HTML pages, XML files, and virtually everything else that requires any typing."

Vim is also a great editor, choosing between them is really a matter of personal preference.

They are both especially good if you have to deal with several languages (VB.NET, C#, HTML, XML, JavaScript, SQL, etc., etc.) over the course of a day. If you only ever write C#, for example, then sticking to Visual Studio makes more sense.

Luke Girvin
+60  A: 

Emacs is great because it is so fully and overwhelmingly configurable it's ridiculous. Want a keystroke to format the last block of text a certain way? You can write one. Want Emacs to behave differently according to different classes of files? You can make it do that. In fact you can make Emacs do pretty much anything you want. There are even calculators, calendars and web browsers for it!

Another advantage of Emacs is that you can do things real fast by using the keyboard for pretty much anything you can possibly think of. The default setup provides such a ridiculous depth of functionality it takes a long time to master but once you have it just feels sooooooo right. You can get stuff done without obstacles in your way and if anything pisses you off you can just go change it. That is so incredibly powerful it's ridiculous.

Keep in mind that the humble text editor is the interface between you and getting the computer to do stuff, and so is probably one of the most important applications you will ever use.

Oh and yet another advantage of using Emacs (BTW there is a very nice Windows implementation so this is emphatically not just for use in Linux - I am in Windows now and use Emacs a lot) is that you get the same custom configured environment for doing different things. OK, now I'm going to program in Ruby - same environment. OK, now I'm going to program in Python - same environment. Often when you learn a new language or system you have to learn a new IDE - Emacs gives some real consistency and let you carry your skills through to other programming languages.

As mentioned by others, the fact that it's been around for so long means it's a) very reliable and solid, and b) got a huuuuuuge bunch of add-ons available out there. It has pretty printing for most programming languages built in right out of the box by the way, as well as some seriously smart indentational rules. Boy does this thing rock.

There are no other editors that even compare to Emacs and Vim for configurability and speed, full stop end of sentence. That's why they're still around - you can't beat the best :-)

Oh and of course there's a real competition between the two; as you can tell I'm an Emacs guy but I don't begrudge the Vim users their preference - hey I mean there's a Vim mode in Emacs so as far as I'm concerned it's just an Emacs module anyway ;-)

There are, however, cons to using Emacs of course. The whole thing about it being slow is pretty much a non-issue these days IMHO - computers are just so much faster now it doesn't really matter. One problem is not every language has a mode in Emacs which can be a pain (C# for example only has some half-complete modes out there, nothing serious which irks me considerably), there is a super-big learning curve - it takes a while to get used to it and you might hate it to begin with, but once you get used to it, boy does that work pay off :-), the extension language is ELisp, a slightly archaic form of Lisp - there is a learning curve with this too but it's such a great language that again it's worth it. Oh and another con is that at work you might be forced to use other editors, that can be heartbreaking :-)

Steve Yegge (I seem to be linking him a lot, he is a great blogger) has some fantastic posts on Emacs:-

  • Effective Emacs - Advice for becoming very efficient with Emacs, along with some arguments in its favour.
  • The Emacs Problem - On why Lisp is a good choice as the extension language for Emacs.
  • Steve's .emac file - Gives an idea of the configurability of Emacs.
  • Looking at Emacs 22 - Steve takes a look at Emacs version 22, loads of really interesting tips on how to achieve some cool stuff in Emacs.
  • Emergency ELisp - Advice on programming ELisp, again gives an idea of the flexibility of Emacs.
  • JavaScript Mode for Emacs - Steve programmed his own JavaScript mode for Emacs, again some very interesting points about Emac's extensibility.

Anyway, hopefully that gives you an idea why Emacs rocks! :-)

Yes, Emacs is a good operating system, but it lacks a decent text editor.... ;)
Roman Plášil
Emacs is great — I use it a lot — but some languages are better done in other ways. Java's so bureaucratic that it's better with an IDE; I imagine that C# may be the same way.
Donal Fellows
That was beautiful!
This answer is simply too big. Could have been lot more smaller.
Akshar Prabhu Desai
I wouldn't say Emacs has a "super-big" learning curve. If you want to write highly customized extensions, then yes, you'll need to learn ELisp. But otherwise, you mainly need to know C-x C-s, C-s, C-r, M-x shell, C-x C-f, M-x 2, M-x 3, C-x o, C-x 0, C-x h, C-space, M-x apropos, C-g, M-%, C-x u, and C-M-\ (respectively save, search forward, search backward, start shell, open/create file, split screen vertically, split horizontally, switch between sub-windows, close sub-window, select all, set mark, search for command, cancel current command, find/replace by regexp, undo, and indent region).
Hoa Long Tam
I don't understand why doing everything with a single editor is an advantage. Different tools work better for different things. That's not a bad thing.
Billy ONeal
+3  A: 

They work. They do everything they need to. They are available for pretty much every platform. There are lots of plugins/extensions for them.

While the original 'vi' or 'Emacs' is probably aren't used that much, pretty much every editor is a modification or derivative of one one or the other. For example, Vim, gVim, XEmacs, TextMate and so on.

emacs has more users than xemacs. xemacs was an ideological fork.
Justin Smith
+3  A: 

I've never learnt to use Vi or Emacs

I spent a large amount of money on an editor (SlickEdit) almost solely because it supported Vim emulation (not solely obviously, or I'd just use Vim!), because I personally am a lot faster using the vi key bindings. Of course, everyone has their own favourite environment; try different things and use what works for you.

The fact that I can keep my hands on the homerow 90% of the time speeds me up a lot.

What were your reasons for using SlickEdit?
@intuited: the excellent auto complete, editor component, in built scripting, configurability (without being _too_ overwhelming), among other things. It's a pity it costs so much, really, because despite all that, I believe it to be overpriced.
@Bernard: hmm... vim has all of that stuff, some of it in spades (maybe you felt there were too many spades?). Can you give a couple of specific examples? I'm curious about what I'm missing.
+36  A: 
Ben Collins
(Credit to xkcd: )
include the mouseover...
In Emacs 23 and above you *can* actually use M-x butterfly ... give it a try...
Jonas Gorauskas
+3  A: 

I was an Emacs fan, but the frequent use of Ctrl gave me wrist pain. So now I use Vim for ergonomic reasons. I also use the Dvorak keyboard layout for ergonomic reasons, so I had to do some significant remapping to get the movement keys in a sensible place. Here, I'll share:

" Remap movement keys for Dvorak layout.
" Use d, h, t, n to move left, up, down, and right.
noremap d h
noremap D H
noremap h j
noremap H J
noremap gh gj
noremap t k
noremap T K
noremap gt gk
noremap n l
noremap N L

" Reassign the keys we overwrote.
noremap k d
noremap K D
noremap l t
noremap L T
noremap j n
noremap J N
Christian Oudard
Hmmm.. I was going to say that «mapping CAPS LOCK to ESC is pretty helpful for ergonomics if you're using `vim` regularly. Unless you actually use CAPS LOCK. I set up the remap after I realized that I wasn't even using it when typing things like CAPS LOCK — I just hold down the SHIFT key.» .. actually I did say that; I'm editing now. I realized that this kind of remapping is useful more for speed and flow than for relief from physical symptoms; it might even aggravate them, since reaching for ESC probably gives your hand a stretch.
I actually use a two letter sequence, vw as my escape from insert mode.
Christian Oudard
+34  A: 

I personally believe they're popular because they give you all the features you need for editing, interfacing with the system without leaving the editor and most importantly...


You can escape to a shell, run commands, compile, all without lifting your hands from the keyboard. Once you get used to having everything literally at your fingertips, lifting your hands to use a mouse on some level gets you out of the programming zone.

Nail on the head :-)
Yes, yes, yes! I've been saying this for years: mouses are for people that are just farting around on a computer, not for a programmer that needs to get stuff done!
Pointers are really useful for interacting with visual elements that can't be identified through text, and having a smooth way to scroll by varying amounts is useful for browsing. That being said, you have to be a bit silly to want to use a mouse; I don't understand why it's so hard to find a usb keyboard with a built-in trackpad like a laptop. Trackpads fill otherwise wasted real estate; it's like another row of keys that do awesome things.
Also.. I'm pretty sure you can do all of the things you listed in Visual Studio with the keyboard. You'll probably need to alt-tab over to a command prompt window, or hit Win-R, for some of it.
Probably the only sensible reason I see here. +1.
Billy ONeal
+8  A: 

I wonder if there's a generational difference in answers to this question.

For "old-timers", particularly people who have been using Unix for a long time, these may have been the only two decent editors when they started. So once you used one or both for a decade or so, there was certainly no reason to switch to a new one.

In a situation with shared computers, or having to log into one of many computers with a shared account, or if you weren't a sysadmin (typical of all university computer use not so long ago), you really couldn't rely on 3rd party add-ons and had to make due with things that either came standard with the OS or were so common that they were likely to be installed in virtually any computer you were likely to come across. And it didn't hurt if the editor you were expert in would work with the most basic, or even broken or incorrectly set up, terminals, slow connections, no mouse, etc. There are still many people or jobs where this logic still applies, though it may seem foreign for somebody whose main experience is with a single PC that they control.

That all said, there are still good reasons why even young-uns might use one of these venerable choices. They're both extremely powerful. Power always comes at the expense of ease of use. There are many editors that are slicker, prettier, easier to learn and use. But probably none that can compete with emacs for being feature-packed, extensible, and ridiculously programmable. (I've used vi plenty, but not as my main editor for many years, so I don't feel as qualified to make such a strong statement as I do for emacs.)

Larry Gritz
You're right that EMACS is "ridiculously programmable." It's so off-the-charts so that it gave rise to the joke, "Some people like EMACS. I prefer BSD."
John Franklin


I wonder if there's a generational difference in answers to this question.

I'm Bernard, I'm 19, and I'm a Vim user. *hi Bernard*. :P

+8  A: 

Programming hasn't changed all that much in the past 30 years. While design principles and approaches to programming have seen many changes, the actual coding part is pretty much the same it was when C first appeared. Since Emacs and Vi(m) have been around for long, they have been adapted perfectly to the needs of programmers, and since little has changed, they still fit the description. That, and old habits die hard.

At one point, as a UNIX user, you'll end up using Vi(m) or Emacs because everything else is broken or not available. That's when they'll get you hooked. Resistance is futile.

+17  A: 

I'm semi-competent with vi keybindings, but I prefer Emacs overall. The reason these editors have such fervent adherents is because the editing model they provide is more powerful than newer systems, which is why providing "vi keybindings" or "emacs keybindings" isn't enough, even if you aren't using any extension features or customizations for emacs or vi.

I'm only going to talk about Emacs' model because I understand it best. The common model for text editing today involves a buffer of text, in which text can be inserted, deleted, selected, and cut/copied/pasted to the system clipboard.

Emacs buffers, of course, can support these operations. Along with tracking cursor position for each window they're visible in, they also keep track of "marks" made in them. The text between the "point" (cursor position) and the "mark" is called the "region", and roughly corresponds to the selection in mainstream editors.

The difference is that Emacs keeps track of the last several locations the mark was set at in the mark ring, and you can return to them with a keystroke (or two, depending on your configuration). I find this extremely useful, especially since a lot of Emacs commands that change your location in the buffer set the mark at your old location. An example is when I'm editing a Python module and need to add an import statement to the top of the file. The keystroke for going to the top of the buffer (Alt-<) sets the mark. I add the import statement. I press Ctrl-u Ctrl-Space and I'm back where i started. I can keep doing this to cycle back to previous positions as well. (Maybe I needed to select some text while adding that import statement.)

The other (and more well-known) Emacs difference is the kill ring. Most of the keystrokes for removing text from the buffer save text to the kill ring, which can then be recalled with the "yank" command (Ctrl-y). The essential feature is that subsequent yank commands retrieve older killed text. So you can kill several sections of text in a row, then retrieve them in order. You can also cycle through the kill ring with Alt-y after a yank, removing the retrieved text and inserting the next entry in the ring.

Emacs had these features in 1978. The only other major system to adopt them to any extent is NeXTStep (and now inherited by Cocoa). Other tools provide more features for specific tasks, can be extended in languages way easier to use than Emacs Lisp, and have nicer visual interfaces... but Emacs remains better at text editing. Which is why, once you know how to use it, it's so hard to quit.

ah, cutting several pieces of text and having all still available to paste back in? you have convinced me - i gotta learn emacs!
vim kill ring: press u in command mode.
@grepsedawk: vim's kill ring is really the 1 through 9 registers, but it only works for line-wise (as opposed to character- or block-wise) deletes. There's an extension on somewhere that implements an actual kill ring. You can also get some of this functionality in the desktop itself by using a clipboard manager that supports a history list. I think most or all of them do; I use a leaner one called parcellite that does have this feature.
+3  A: 

Joel Spolsky might say: "You have to learn C, and you have to code C using vi or Emacs".

+3  A: 

Since they've both been around a lot of time almost all of the little nags that you will encounter with any other editor have already been simplified. Another thing in their favor is that they pretty much don't need a mouse which speeds up a lot of stuff.

They both do have a very steep learning curve but, I assure you it's well worth it. For me the occasional <esc> suited me and hence I'm a vim convert. All hail Bram Moolenar!! :D

+11  A: 

I don't know about Emacs (I could guess, but someone more knowledgeable would be much better at this). But if we're talking about about vi/Vim, I wrote an article some time ago which should clarify why this is so popular after 30 years of existence:

"Why, oh why, do those nutheads use vi?"

I would in any case recommend any serious programmer to invest the time to master a powerful, multi-platform and predictably-long-lasting text editor. Currently vi and Emacs are probably your best bets.

For me, your last paragraph hits the nail on the head. I learned emacs 25 years ago and haven't had to learn another editor since. I've _never_ had to ask the question "what's the best editor for this [platform|programming language]. Languages change, platforms change, but my editor doesn't. I also know vi, which has the selling point of being on every *nix box everywhere, whereas emacs sometimes has to be installed.
Bryan Oakley

In a word: Speed and Power.

If you want hand-holding, you know where to go ;-)

Paragraph 1 is this is useful.Paragraph 2 is snide and childish.
Richard Ev
The ability to readily integrate with external tools like `wc` is also very useful.
+6  A: 

You can learn one powerful text editor and be nearly sure that it's available on every platform imaginable.

Learn once, use everywhere. That's why I've started using Vim.

+3  A: 

If you don't use Vim, Emacs, or Eclipse, the real programmers will kick sand in your face. Besides that, they are incredibly powerful and incredibly ubiquitous. They are free, they are multi-platform, and once you learn to use them they are amazingly powerful.

If you watch people using "normal" editors (I call them "inserters" because they do little besides insert and save text) you see a lot of mousing and navigation and the code slowly changes in response to typing individual characters or moving the mouse. If you watch people who have spent some time with Vim, Emacs, or Eclipse the code comes alive and dances on the screen. Entire blocks of code are sorted, moved, replaced, refactored, renamed, commented and uncommented, indented, syntax checked, compiled, tested, navigated, and reformatted as you watch. It's actually hard to watch a real Emacs or vi expert at work, because it's a strain to keep up.

The problem is that these editors are friendly to those who have studied them and become experts, but not so much to people to are used to Notepad-style editing. If you like Notepad, then Vim and Emacs and Eclipse are intolerable tools. If they knew how to use a real "programmers editor", they'd have a significant speed increase and a lot less movement and navigation in their editing sessions.

I wrote a little tutorial (ugly, but useful) on how to make peace with Vim and use it like a pro:

Tim Ottinger

If you like the freedom you get from not using a mouse, try the Vimperator plugin for Firefox. It makes Firefox act like Vim.

+2  A: 

I started using Vim in my workplace and boy, I love it ! For some, it will look as though we are mad to waste time typing all those keystrokes (Oh God! You people have to (in Vim) press :wq to just save and quit a file, so much remembering to do !!), but little do they realize that we use these editors and improve our productivity a lot. And it's fun to learn, is it not?

Vijay Dev

I have never been able to learn those program effectively. Every time I got in a rush and had to use something else. I think those programs have a high learning curve but once you know how it works, they are very fast and powerful.


It is hard to explain, because you haven't use it yet.

Personally, I am a Vim/Acme(in plan9port) user.


Simply put, vi and Emacs are just tremendously powerful tools for programmers.

They've been designed and refined over 30+ years of use and once you get past the learning curve, they enhance productivity with regular expressions transformations, sorting, shell integration, and so on.

Like many things in programming and in general, they require some time to learn at first. However, stick at it for just a couple of weeks, and you'll already get benefits. The benefits multiply month by month. Experiment, and enjoy the rewards.

Jon DellOro

Good comments all. I like the prettiness of newer editors, but when I've got to do real work, I pull up my 20-year-old Emacs. Real work like:

  • Rewriting massive amounts of legacy assembler code of a customer's UI. With a few macros, it does 80% of the job in no time.

  • Code merge when 2 programmers change the same code. With a little macro using buffer compare, you can zip along from change to change and quickly reconcile the differences.

  • Need a simple checkbook balancer application? It's just a couple of macros.

  • Conversion of massive .csv files to some other format.


Mike Dunlavey
+3  A: 

This is a pretty insightful question, because although both are undeniably powerful and influential, some of the "johnny-come-lately" editors are actually catching up, with a much less onerous learning curve.

Although Emacs and Vim certainly can do all the new fancy tricks, they are definitely not afraid of showing their age.

One concrete example: VimScript. This is the scripting dialect you use to extend Vim itself.

Vim allows you to script in modern programming languages, but the default scripting language is (please forgive me Vimmers) freaking awful. Sure, it's powerful, but so are Ruby and Python, and I'd much rather write editor extensions using those (which is incidentally possible with the right compiler options).

Most notably, anyone who has taken the time to actually climb the learning curve has essentially "wired" themselves into working with Vim (or Emacs) -- which is why you seldom find experienced people who are adept with 'both' of these classic editors. Hence all the "religious wars".

It's a classic case of emotional-intellectual-and-muscle-memory lock-in.

Nevertheless, there are certain aspects of Vim and Emacs that (so far) seem to be unmatched in any of the current generation of high-end text editors. If you are curious about learning one of them, try to find a physical human being who uses them and watch them work. Ask them questions and ask them to try not to "sell" you. If you are impressed by what you see, act accordingly, otherwise, look at one of the newer high-profile editors, many of which actually have a "Vim Emulation mode".

I think it's more a case of diminished need to learn another editor, because the one you already know can do pretty much anything in an efficient manner. I know vim, and would like to take the time to learn emacs, but it's pretty low-priority since I'd mostly be doing it for the sake of curiosity and a gain in perspective. It's a lot like learning a programming language in a new paradigm: it's mind-expanding, and helps you with finding different approaches to problem-solving, but doesn't have a lot of short-term payoff.
VimScript (properly known as VimL) is useful in that it's very well oriented for scripting vim. As such, its facilities for general-purpose programming are somewhat limited and out of the way. Still, it's got the basics: prototypal object orientation, first-class functions (erm, mostly), map() and filter() functions, dictionary and list literals, string manipulation with regexps, etc. For complex stuff you can pull in python or perl or haskell or whatever; however, this is somewhat frowned upon, at least when not entirely necessary, because it reduces portability and memory efficiency.
The problem with using a "Vim Emulation mode" is that it's a shallow emulation mode. For example, if you yank text into a register, you can't manipulate that text using a function or a command like `:let @" = substitute(@", '\(rocks\|sucks\)', '\=euphemisms[submatch(1)]', 'g')`. You also can't quickly repeat that command for subsequent pieces of copied text. When I use tools with a "vi(m) emulation mode" I usually spend more time trying to do things that are beyond the limits of the emulation than I save by using the vim-ish-ness of what they do emulate.
+4  A: 

I like vi (gVim) because it doesn't break your train of though. This is VERY important when developing.

Take this example:

You're writing a method that uses another class. The other class is in another file, and you have to peek a little bit and come back to your editing (probably to look at the parameter order).

With a "modern" editor, using tabs (or a list at the left like TextPad), you'll have to do the following:

  1. Raise one of your hands from the keyboard.
  2. Look for the mouse (you don't always find it inmediately, it may take a second or half second)
  3. Point the right tab (and make sure you don't click in the line between that and another).
  4. You take a look at what you wanted (the scroll was already there)
  5. Click again on the tab to go back to your initial file.
  6. Take your hand back into the keyboard, (take 1 second)
  7. Start typing

This may not seem too big a deal.

The problem here is that the steps, 2, 3, and 6 where not part of what you were doing (typin ) and you were disconnected.

This could be very distracting.

Now with vi you'll do something like the following:

  1. [esc]
  2. ':bu #' [enter] (change to the last file)
  3. Peek at the file you wanted
  4. ':' [upkey] [enter] (come back to the original)
  5. o (enter text in the next line)

The point here is, since you have to raise your hands from the keyboard, you're not disconnected. You type what you want, as if you were typing a method name. You're typing [esc]:bu #[enter] that means:"take me to the other file" and then you type :[upkey][enter] that means "Ok, now take me back"

When you're back, your hands are right where they should (at the keyboard) this happens in a fraction of second (OK, OK, perhaps a second) but you never have to switch to a "mouse mode".

This is the main benefit from vi (and Emacs I suppose).

The big problem of course is: It takes a lot of time and effort to learn those basic things. And in the mean time your productivity is ZERO. And this is a big problem. That's the reason why it is hard to learn.

The way I learned it was pretty much like Rocky in Rocky mmhh what was that? Rocky IV? When he ties his left arm? I had to program on this AIX machine, and there wasn't anything in there but vi.

Later I benefitted from this, for instance with the Unix option "set -o vi" is very handy to work on the command line.

Nowadays I use it when I want to perform a quick edit, and don't want to create a new project on the IDE and wait to be loaded, etc.

Additional note:

IntelliJ IDEA does a terrific job in this area.

Everything is "hotkey"(ed). So in this example I would have to just Ctrl + P.

Eclipse is not that well integrated and that's the reason I don't like it so much (it makes me have to grab the mouse).

"You're writing a method that uses another class. The other class is in another file, and you have to peek a little bit" ...Actually, there's no reason why you can't configure Vim to automatically display a context-sensitive section of the other file automatically
The only reason is, "you ( well me ) don't know how" :) :) The point is you don't leave your keyboard. How is that performed anyway?
Hmm, there are a lot of ways to do it actually (it is Vim afterall:) Probably the mainstream way is to use ctags. You can make Vim treat all class and method identifiers as "hyperlinks" -- and then you can just c-T on your identifiers to jump to the definition/docs in a new buffer or a split window.
.. but yeah, I got your point about not leaving the keyboard. It's a good one. I was just adding along to emphasize that Vim allows you to rethink things to be as insanely efficient as you want to be.
Ctags, yes of course. I've used that before. I don't know if is already integrated, but when I used it I had to run it over my classes and then c-T. I meant gVIm for really quick editing, when you don't even need to setup a project. Something like that.
Sounds familiar, I actually don't use ctags myself and opted for a custom-made VimScript solution that auto-recognizes my code as hyperlinks. That just goes back to the "million ways" to get things done in Vim and Emacs.

I learned software development on Notepad. I worked my way up to EditPlus2 (IIRC), which was a slightly beefier notepad-like program. It had neat features like pattern-based search-and-replace, line numbering, whitespace control (tabs/spaces/indent level). Somewhere along the line, I moved to vim and gvim, and discovered that it had more neat features than I could even use. Some of the main things I like about it...

  • Integration with my software development environment. From within the editor, I run the make command. I then get to step through compiler warnings and errors one at a time, across multiple files, as efficiently as any other GUI IDE. It also integrates with ctags well, which lets me jump to function declarations/definitions the same as other GUI IDEs.
  • Very powerful search-and-replace and similar batch commands. Oftentimes if I need to do some batch processing of a logfile or similar, I'll just load it up in vim. I can perform a series of destructive operations, with full access to an undo/redo buffer. This is much more efficient than piping a sequence of commands through several layers of grep/awk/sed, and having to re-do the operation every time.
  • Universality. Everywhere I go, I can get vim or at least vi. I believe it's actually a part of the Linux Standard Base, implying that all compliant Linux distributions will provide it.
  • Syntax highlighting. It's never perfect, but I don't think I've seen a better editor in terms of universal syntax highlighting. Visual Studio may do C or C++ better, but it'll fall on its face as soon as I start looking at Python or a Bash script.
  • Command-line integration. I can invoke commands from within the editor itself. I find myself referring referring to operations to grep lines out of files, or to browse through the filesystem, quite frequently. Relatedly, I can pass a directory to vim, and from within the editor, navigate to a file.
Actually, vi is required by posix, so lsb includes it for posix compatibility.
Justin Smith
+47  A: 
Steve Lacey
what does the vertical axis represent? what's the thing about emacs? why is the curve crazy? lol
hasen j
+1 that is hilarious
@hasen j - My understanding is the y axis = difficulty, x axis = time. emacs has the crazy curve because it can do everything...even go back in time. lol.
@dotjoe - looks like an archimedes spiral.
I interpet it as multiple values of difficulty at the same point in time - because you can choose as a user how far to go down the rabbit hole of emacs productivity and extension features (you don't have to use your undo as a branching tree, you don't have to define keyboard macros on the fly, you don't have to save text, buffer positions, and window configurations into registers, you don't have to learn elisp and implement an entire application within emacs... etc.)
Justin Smith
@Justin Smith: I think actually it's that you end up learning a lot of those things simultaneously: it works on multiple levels at once. Though this theory breaks down in light of the fact that the image's emacs curve stops; it should probably rise exponentially to infinity as you get into building more and more complex custom functionality.
+5  A: 

FWIW, I'll add another thumbs up for vi or Vim if you wish. Either editor is very powerful and a venerable favorite among seasoned programmers for a number of reasons:

  1. Not mouse driven: this is particularly important if you consider the "not breaking your train of thought" idea presented by Oscar recently.

  2. Integrated regular expressions: most editors include regular expression search and replace support somewhere; however, it is usually hidden behind a checkbox in a dialog somewhere. Once you have really gotten comfortable with regular expressions, you'll have trouble editing without them.

  3. Scriptable: this is less important but it is a nice power-user feature. My biggest problem here is that the scripting language is always horrible... vim has VimScript and emacs has Lisp. I know that you can extend Vim with a variety of languages (depending on the compile-time options) and I assume that emacs has grown a similar capability but isn't it time to embed a more suitable programming language in the editor already?

  4. Portability/Accessibility: both editors are available virtually everywhere. IMHO, vi is a bit more accessible but your mileage may vary significantly. The real bonus here is that the basic vi commands that I learned on SunOS 4.1 in the mid 90s work on my Win2003 server at work and my MacBook Pro at home.

  5. Built by programmers, for programmers: this point is oft forgotten... these editors were built from the ground up as efficient tools to edit text. They grew to look pretty as time went on, but they were built specifically for editing source code. Most IDEs have an editor because they need one not because they want to write a really good source code editor.

The last point is probably the most important. The few editors that I have found other than vi that I really like have always been standalone editing products like Visual SlickEdit, CodeWright, and BBEdit. Each of them exists as an editor first and IDE next which is why they excel as working environments.

You can always launch a makefile (or Ant Build file for that matter) based on a hot-key binding or menu item from within a stand alone editor and get 90% of what you get with an IDE. The debugger is always the hard one... However, it's a real pain to learn a new environment with every release of an IDE and, god forbid, you switch languages and have to learn a whole new environment. If you spend the time to learn a nice flexible editor and automate the tasks that you do 90% of the time, then you can seamlessly go from language to language and environment to environment and still maintain your comfortable editing environment.

Now a more interesting question would be which one you choose and why hehehe... that's a nice trolling question. I say "learn one and learn it well, you won't regret it".

.. or learn both, and by the time you're done you won't live long enough to regret it
"isn't it time to embed a more suitable programming language in the editor already?" elisp is a great language, and the huge amount of elisp extensions, and the fact that the majority of emacs is written in elisp is a testimony to this. I agree that vimscript is a joke.
Justin Smith
vimscript (properly termed VimL) is quirky, and not really ideal, but it's definitely usable. I definitely wouldn't call it a joke. It's useful that it's oriented towards executing Ex commands, but this Huffman coding also causes some inconvenience. The core language is about on par with php 5.2, and the lack of library support is probably due to the fact that it's so convenient to pull functionality in from the bindings with other languages or from external tools. I'd still prefer for it to be Python, but it's far from a writeoff.
+1  A: 

You do not merely "use" an editor: You become one with it.


I learned and became a fan of Emacs when at a previous job my boss and mentor used Emacs exclusively, he was a self professed 'emacs-jock', and some co-workers decided to perform a variation of a 'Rick-Roll' on him because of his fervent Emacs evangelizing. More on that later.

Since I spent many hours paired with my boss, learning Emacs was essential to my understanding of what he was doing, and I learned the value of memorizing one set of keyboard bindings and using them for all text manipulation tasks. My job also required me to work on remote servers, and instead of using one editor for working on my box, and another on the servers, I started using Emacs for everything.

It was a great boost to my productivity, and simplified my development environment. I've recently become serious about learning Lisp, and cannot foresee a development situation where a IDE would be better suited. One obvious missing feature that IDE fans point out is lack of a debugger, I've personally never found debuggers very useful, I prefer reading stack traces, using unit tests, and reading logs to analyze my code. And is a matter of personal preference.

Now back to the 'Rick-Roll'. Via an old laptop on his desk that was functioning as a server for our group wiki, integration, and source control repositories, a script was installed that would run the laptop's speech synthesizer, reciting 'vi is the only editor for me!' over and over again.

"One obvious missing feature that IDE fans point out is lack of a debugger"GUD ships with emacs by default.
Justin Smith
Debuggers would be much more useful if you could step *backwards*.

I have used Emacs, vi (nvi), and Vim extensively (in terms of features and the editing model, Vim is more similar to Emacs than it is to vi, so I list them separately). I mostly use Emacs because nowadays computers come with enough RAM and CPU to handle Emacs, and the extension language is a Lisp dialect and most of Emacs is written in that extension language. Having a real, usable language for extending my primary working environment has obvious advantages. Not to mention the fact that you can use the reflective features of Emacs Lisp to interrogate inner workings of the editor whether they are documented or not.

The real advantages of these editors are things you would never notice without being experienced with them. Having things like a mark ring, a kill ring, an undo tree, incremental search through open file names, keyboard shortcuts for window configuration, integrated grep in the current file's directory, opening a file in less time than it takes to put your hand on the mouse and find the "file" menu, are things you will never miss if you do not learn how to productively use them.

Justin Smith

Back in university during the early 2000s, the only OS available to CS students were UNIX. The mouse was barely working and the equipment look like it was from the 80s. We were given 2 choices to navigate around and write code, Vi or Emacs. That is why I'm still using Vi to code nowadays.

Thierry Lam
I've hung around a lot of universities in the early 90's. They certainly were using Windows for some of their classes. Get your facts straight.
LOL,in some of the courses during certain years, students were only allowed to use UNIX machines, that's what I meant. You don't really have much choices to use windows on for those cases.
Thierry Lam
+1  A: 

When you write code, it is not enough that the code you write compiles and sort of runs correctly. Code need to be relatively bug free, relatively easy to read, easy to debug, easy to modify.

Tools which help with these are a premium. *Emacs and vi are tools that do it and do it well *. Most other IDEs/editors do not do it as well.

Sure there are newer tools that can do the job, but it takes effort to learn them. In ten years time, you may be programming a tablet using Haiku or a cell phone using the p-system. There is no guarantee that these other tools will be there, even with Windows and Unix environments. Emacs and vi will be.


Once you are on a Linux terminal or sometimes when you have nothing but access to shell. The only option you have got it Vim or Emacs. So a lot of people end up using it. And because there are so many people out there this tool has become popular.

It's good to know it but I wouldn't invest time learning Vim or Emacs or give up my current Notepad++/EditPlus for it.

Akshar Prabhu Desai

I was googling around for for this question too and came across the article "Emacs isn't for everyone". It definite makes for a good read.

Victor T.

vi and Emacs are racing bicycles. They take time and effort to master. There are people who love bicycles and spend the time and effort just because they love bicycling. For them, getting places faster is a bonus. For others, the return on investment may not be enough to justify it.

To make this a viable analogy we have to assume it's 1910. Your options are to walk (Edlin, too slow), get a horse (hire a secretary, big expense and not all that fast), get one of them new-fangled Model T Fords (Notepad, easy to learn, top speed 35 mph) or get a bicycle.

So what's Eclipse? A 1920's race car I suppose. Or something.

Mark Lutton