Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

How would you compare these editors? What are the pros and cons of each?

[note] This is not meant to be answered by those who "hate one and love another" or those who haven't used both.

share|improve this question
    
M-! emacs RET It's like search google for "google" –  Seamus Aug 28 '10 at 9:14
5  
Duplicate of SO question: stackoverflow.com/questions/1430164/… of ubuntu askubuntu.com/questions/804/… and programmers programmers.stackexchange.com/questions/1271/… Gotta love the proliferation here. –  Trey Jackson Nov 4 '10 at 16:03
6  
I'm surprised nobody has mentioned XKCD 378. –  tedder42 Mar 10 at 18:12
4  
Notice how these questions never bother asking for a comparison with Ed, the one true WYGIWYG editor! –  Mark K Cowan Jun 11 at 21:12
    
@tedder42 Then you might as well state "Mel"... –  Tobias Kienzler Nov 12 at 8:29

14 Answers 14

up vote 240 down vote accepted

I use both, although if I had to choose one, I know which one I would pick. Still, I'll try to make an objective comparison on a few issues.

  • Available everywhere? If you're a professional system administrator who works with Unix systems, or a power user on embedded devices (routers, smartphones with Busybox, …), you need to know vi (not Vim), because it's available on all Unix systems and most Unix-like systems, whether desktop, server or embedded. For an ordinary user, this argument is irrelevant: Emacs is easily available for every desktop/server OS, and since it supports remote editing, it's enough to have it on your desktop machine anyway.

  • Bloated? Emacs once stood humorously for “Eight Megabytes And Constantly Swapping”. Right now, on my machine, Google Chrome needs about as much RAM per tab as Emacs does for 100 open files, and I won't even mention Firefox. In the 21st century, Emacs bloat is just a myth.

    Feature bloat isn't a problem either. If you don't use it, you don't have to know it's there. Emacs features keep out of the way when you don't use them and the documentation is very well organized.

  • Startup time: Vi(m) proponents complain about Emacs's startup time. Yes, Emacs is slow to start up, but this is not a big deal: you start Emacs once per session, then connect to the running process with emacsclient. So Emacs's slow startup is mostly a myth.

    There's one exception, which is when you log in to a remote machine and want to edit a file there. Starting a remote Emacs is (usually) slower than starting a remote Vim. In some situations you can keep an Emacs running inside Screen. You can also edit remote files from within Emacs, but it does break the flow if you're in an ssh session in a terminal. (Since XEmacs 21 or GNU Emacs 23, you can open an Emacs window from a running X instance inside a terminal.)

    Turning the tables, I have observed Vim taking noticeably longer to load than Emacs (vim -u /dev/null vs. emacs -q). Admittedly this was on a weird platform (Cygwin).

  • Initial learning curve: This varies from person to person. Michael Mrozek's graph made me chuckle. Seriously, I agree that Vim's learning curve starts steep, steeper than any other editor, although this can be lessened by using gvim.

    Since I've dispelled a couple of Emacs myths, let me dispel a vi myth: a modal editor is not hard or painful to use. It takes a little habit, but after a while it feels very natural. If I was to redesign vi(m), I'd definitely keep the modes.

  • Asymptotic learning curve: Both Vim and Emacs have a lot of features, and you will keep discovering new ones after years of use.

  • Productivity: This is an extremely hard topic. Proponents of vi(m) argue that you can do pretty much everything without leaving the home row, and that makes you more efficient when you need it most. Proponents of Emacs retort that Emacs has a lot of commands that are not frequently used, so don't warrant a key binding, but are damn convenient when you need them (obligatory xkcd reference).
    My personal opinion is that Emacs ultimately wins unless you have a typing disability (and even then you can configure Emacs to require only key sequences and not combinations like Ctrl+letter). Home row keys are nice, but they often aren't that much of a win because you have to switch modes. I don't think there's anything Vim can do significantly more efficiently than Emacs, whereas the converse is true.

  • Customizability: Both editors are programmable, and there is an extensive body of available packages for both. However, Vim is an editor with a macro language; Emacs is an editor written in Lisp with some ad-hoc primitives. Emacs wins spectacularly when you try to do something that the authors just didn't think of. This doesn't happen every day, but it does accumulate over the years.

  • More than an editor: Vim is an editor. Emacs is not just an editor: it's also an IDE, a file manager, a terminal emulator, a web browser, a mail client, a news client, ... Whether that's a good thing or a bad thing is a matter for debate. But you can use Emacs as a mere editor (see “feature bloat” above).

  • As an IDE: Both Vim and Emacs have support for a lot of programming languages and other text formats. Beyond the basics such as syntactic coloring and automatic indentation, both have advanced IDE features such as code and documentation cross-reference lookups, assisted insertions and refactoring, integrated version control, and the ability to initiate a compilation and jump to the first error.

    One domain where Emacs is plain better than Vim is interaction with asynchronous subprocesses. That's when you start a long compilation and want to do something else inside the same editor instance while the compiler is churning. Or when you want to interact with a Read-eval-print loop — Emacs really shines at this, Vim only has clumsy hacks to offer.

share|improve this answer
3  
Learnt a lot here. Thank you. –  boehj May 5 '11 at 4:31
10  
I cannot agree with the point "More than an editor". Vim has also many plugins, including ones that turn it into a file manager or an IDE (like vim-latex). –  rozcietrzewiacz Jul 29 '11 at 12:36
2  
This made me feel small... –  gnometorule Dec 25 '11 at 4:10
4  
@rozcietrzewiacz: Yeah, but can you browse the web in Vim? Read email? Check your RSS feed? I don't think you can deny that Emacs is just plain more powerful, though the usefulness of that power depends on what you're looking for. –  musicfreak Feb 19 '12 at 10:45
1  
@Bananguin Emacs is better at anything that involves interacting with a REPL. For example Proof general is very nice (of course it's a very narrow application domain). Emacs is good at doing stuff that nobody thought of before: Emacs Lisp is a lot nicer than Vim's macro language. Emacs tends to have better support for indenting source code but I don't think it's so much a flaw of Vim as a lack of libraries (the Vim support tend to be limited to syntax highlighting). –  Gilles Aug 22 '13 at 12:18

I'll post what I think are the main benefits of each:


Emacs has considerably more extensions to let you do tasks that are only vaguely text-editor related, like browsing the filesystem or messing with version control, and extensions that are in no way text-editor related, like reading RSS feeds. If you want an environment instead of just a text editor, Emacs is going to be better than Vim. I also think Emacs is much easier to learn, despite what some would have you believe:

Editor learning curve comic

In particular, I think a novice Emacs user will be faster than a novice Vim user


On the other hand, Vim is undeniably faster. It seems like this is a core part of the argument, but in my opinion there's no contest at all; I consider myself a fluent Emacs user, and I'm no match for the couple people I know that have an equal knowledge of Vim. The problem is, the number of people that have sufficient mastery of Vim to be that fast is incredibly small (of the ~30 people I talk to regularly who use Vim, I think only one is exceptionally good at it). There's a large gap between the possible speed gain and the actual speed gain you achieve; Emacs users are going to be almost as fast as 99% of Vim users, and (as I said in the Emacs section) beginning Emacs users will probably be faster than beginning Vim users

share|improve this answer
6  
umm... I know vim has more than one version control plugin. and one of those plugins supports all of the popular systems.... if emacs has more... how many of them do you need that do the same thing? –  xenoterracide Aug 22 '10 at 7:06
10  
@xeno I don't know what plugins vim does have, so maybe VCS was a bad example, but I'm highly confident Emacs has far more plugins than vim, because vim doesn't subscribe to the "one program doing everything" philosophy –  Michael Mrozek Aug 22 '10 at 16:25
3  
Would somebody please explain what does emacs graph, given above, means? How to interpret it? –  Andrew-Dufresne Oct 2 '10 at 16:51
13  
It's a "down the rabbit-hole" joke... It's because when you learn emacs, eventually you start creating emacs too. (since Emacs is really just a very large collection of editing macros/routines written in it's Lisp interpreter.) –  Slomojo Nov 16 '10 at 4:20
9  
+1 your speed vs experience is good, but maybe 99% is a little extreme. I mean vim is not "that" hard to master, it only takes a couple of years ;) –  Johan Nov 27 '11 at 9:36

There is a vi available on every unix system (or almost), however you can't say this about any other editor. This is the #1 reason, imo, to learn and familiarize yourself with vi (please note 'vi' not 'vim'). I've never seen Emacs be available in a default install.

I'm not saying don't use Emacs or this is the only reason to use Vim, but when you want to be able to use Unix systems that aren't yours... vi is part of the universal language.

share|improve this answer
9  
@phunehehe if I try using nano I end up with a whole bunch of ijkloOah's in my file... until I realize that I can't use those for navigation. I don't use the arrow keys to navigate. –  xenoterracide Aug 22 '10 at 16:41
3  
This goes double for connecting to slow servers across dodgy connections: the one editor they're guaranteed to have (it is in the Unix spec, I think?) is vi, and vi's command mode makes it much easier to edit files with fewer keystrokes when each keystroke takes several seconds to appear on your screen. Of course, step #1 is usually installing vim :) –  Gaurav Aug 23 '10 at 6:22
6  
@phunehehe I don't use esc. I use ctrl+[ it does the same thing ;) –  xenoterracide Aug 29 '10 at 14:57
5  
+1 for Gaurav's comment. Vi works excellent for emergency editing of config files over a crappy 3G connection on a slow cell phone. –  ultrasawblade Jan 11 '11 at 3:57
2  
+1 for using vi on a cell phone... –  xenoterracide Jan 11 '11 at 9:40

I think they're both awesome. I think either one can do just about anything you can imagine, and they're both so customizable, that by the time you finish customizing them, they're both just exactly what you want them to be, nothing more nor less.

Emacs stands out to me in being a bit closer (although still does not meet) to ISO/IEC standards of usability and consistency for user interfaces, and hence doesn't play as many tricks with your “instincts” about that vim does. The lifetime of instincts you've developed working with other programs won't work against you.

Vim is a completely different model, and in many ways, it is superior on its own in so far as relies far less on Cntrl/Alt sequences, and instead just on its modes, allowing you to keep your hards on the home row and typing faster. But vim is virtually unique, and unless you install some very unusual accompanying software (e.g., Vimperator, Jumanji/Zathura, etc.), the instincts you develop working with vim won't cross over to other programs and vice-versa. That said, I've settled on vim myself. You've got to settle on one sooner or later, for better or worse, since it's difficult to master both.

share|improve this answer

I use both on a regular basis. I view Emacs as a "live in" editor, whereas I use Vim for quick, one-off tasks. Superficially, Emacs is much more bloated than Vim is, and so it really isn't quite so convenient to "Fire up" as Vim, but I also find that the philosophies of user interface from one to the other support this paradigm. Emacs is much more built to keep you inside, making things nice and comfortable so you don't have to leave, whereas vim is much more "Unixy" and sees itself as part of a greater tool-belt.

Many people flee from Emacs due to its heavy reliance on bucky bits, but this is a pretty silly reason to me. The real power that Emacs has over Vim is customizability, and with the power of Viper etc, this really isn't an issue. Certainly Vim-Script provides its own level of customization, and if, say, your favorite programming language wasn't provided with an appropriate syntax highlighter you could certainly cook one up, but Emacs is ultimately a self-hosting lisp-machine, and in the end you can do much, much more fiddling with it. There just aren't such tools as gnus or org-mode in Vim, to name a few. In a nutshell, Emacs isn't just an editor, it's practically a god damned operating system.

For manipulating text, I'd say they're exactly on par.

share|improve this answer
19  
"Emacs would make a great operating system, if only it had a text editor worth a shit." -- I was reminded of this quote. –  amphetamachine Nov 27 '11 at 6:24
    
@amphetamachine I don't get the quote. Does it mean to demean emacs-the-text-editor? –  Tshepang Apr 27 '13 at 8:21

I normally use vim, but they're both great editors.

Learning to use vi was nasty, but I got through it and learned to like it. My most frustrating moments were when the caps lock key was on. You could try with gVim, but one of the biggest advantages with vi and emacs is the ability to do neat stuff while keeping your hands on the keyboard, and gVim is likely to keep you using the mouse. (Learning to play roguelike games at the same time gave me practice with the cursor movement keys, but caused me to try to move diagonally in documents sometimes.)

Emacs is probably more approachable. It's modeless, and you aren't going to screw yourself up by hitting the caps lock key. The idea of controlling the editor through typing letters with the control key down shouldn't be too foreign to modern power users, although the actual keys to do things will seem wild and arbitrary to the typical Windows/Mac OSX user. Again, versions that allow you to use the mouse do you few favors in the long run.

Both require some level of expertise to use effectively. Unlike, say, Notepad, you can't just sit down and edit.

Both are configurable, although for my money writing extensions in the same Lisp the editor is written in makes a smoother experience. (Emacs, as normally distributed, isn't really an editor. It's a Lisp environment tailored for text processing, with a lot of pre-written software, including an editor. Hence the joke "Emacs makes a decent shell, but it could use a better editor.")

I normally use vim because, after extensive training, it feels easier. This may be due to advantages in the mode system, where immense numbers of commands are available using one finger near the home rows, or "baby duck syndrome", which applies very much to editors: once you learn a good one, you generally stick to it.

You won't go wrong using either.

share|improve this answer

I'll put my $0.02 worth in, as I spent quite a few years using emacs and XEmacs and then moved over to vim. To be fair, I had actually used vi quite a bit around 1990-1992 so I was familiar with its user interface.

Emacs

  • Emacs has been described as a lisp system that just happened to be used to write an editor, and there is a grain of truth in this. You can implement pretty much anything you want in elisp if you care to take your time to understand the environment. I can't say I ever got to know it that well, but I did frig stuff occssionally. Emacs and Xemacs aren't totally compatible at this level, so third party scripts may run on one but not the other.

  • It has been observed that RMS and some other prominent Emacs hackers had to retire from programming due to problems with OOS, where Bill Joy, Bram Moolenaar and various other vi luminaries are still at it. Emacs is hard on your pinky fingers.

  • Emacs is a much more catholic system than vi, and is viewed as a canonical example of software envelopment. Along with Netscape, this is one of jwz's contributions to proving this law.

One unique thing I did with xemacs once was to have it running on a machine and open an x session on an xterminal (actually an old repurposed Sun 3/60) in a different room against the same buffer on the same running instance.

Pros: Extensible, more powerful than any other editor known to man, mature integration with pretty much every major free software programming tool.

Cons: Questionable ergonomics, elisp is not easy to learn.

Vim

Disclamer - I went from using emacs to vim about 10 years ago and I habitually use vim on Windows and Unix/Linux based systems.

  • Vi and its descendants have a very good keyboard macro facility for automating editing tasks. The scripting facility in vim isn't as sophisticated as elisp, but you can build it with support for Python, Tcl, Perl and maybe some other systems. I've only occasionally written scripts (outside of .vimrc files) for vim.

  • Vim has a smaller footprint than emacs, but this is not much of a big deal these days.

  • Vim's documentation and on-line help are fairly good. Emacs has quite good on-line documentation, but I don't think it's as comprehensive as vim's.

  • Vim inherits vi's quirky modal user interface, but has the ability to behave a lot like a modless editor now, as you can navigate in insert mode. On Windows it can behave quite similarly to a windows application.

Pros: Good keyboard macro facility, passably good extensibility and scripting, but not as good as emacs. Vim or vi-derived editors are standard on most if not all unix or general purpose linux distros. Arguably better ergonomics.

Cons: Modal user interface feels strange to people used to Windows UIs. Less of an issue with vim these days.

share|improve this answer
    
I enjoyed reading your answer, but I miss the deciding factor. What made you switch from emacs to vim? –  Erik B Aug 8 '13 at 8:33
    
It was just organic - plus vim's keyboard macros work really well. –  ConcernedOfTunbridgeWells Aug 8 '13 at 9:46

Since it hasn't been explicitly stated, I'll add that there is no better programming environment (lisp in a box, slime, etc.) than a slightly modified Emacs distro. All of my programming needs (99%) are taken care of from within Vim, but for all those lisp libraries and routines I write, I have to fire up Emacs to get anything productive done.

share|improve this answer
5  
I sometimes wonder whether this says more about Lisp or about Emacs, and whether that is good or bad... –  Kevin Cantu Oct 26 '10 at 23:29

The main reason I don't use vi/vim is that it's modal. The main reason I do use vi is that it's available almost everywhere.

share|improve this answer
6  
The main reason I use vim is that it's modal. Higher learning curve, but much easier to use once you're used to it. –  Kris Jenkins Sep 2 '12 at 19:46

I use Vim/gVim.

I used to use Emacs, but I found gVim to generally work faster on slower machines, plus, due to its POSIX requirement, vi is available almost everywhere.

When using Vim or gVim, I use the mouse a lot, support for it is great, I think.

I started out using Emacs, because it was easier to use for a novice user. I found usage of nano to be quite error prone for some reason, and at some point I realized I'm much more comfortable with using vi.

Right now, it's a mixture. I use Eclipse and gedit quite often, too. Vim, however, is still my favorite and most used editor.

share|improve this answer

I happen to think that the "vim is modal" comment above is incorrect. Vim has commands. You can do "11aNow is the time for all good men.." and end up with 11 identical new lines of text in your file. That's a command, not a mode. But there's actually a very basic difference in Vim commands vs Emacs commands. I'm not entirely sure I can describe it, but Eric Fischer incorporated Emacs-style line editing in a TTY driver 10+ years ago, and got a paper published about it:

http://www.usenix.org/event/usenix99/full_papers/fischer/fischer.pdf

He found that Emacs style line editing was fundamentally different than vi-style.

So Emacs has an advantage that a lot of other things (bash, gnuplot, zsh, ksh some others I can't think of off the top of my head) all end up implementing Emacs-style line editing.

I should note that I personally use Vim all the time. I'm only a very occasional Emacs user.

share|improve this answer
    
set -o vi in bash or zsh is not too hard to run (or put in an rc file) in my opinion. –  moon.musick Mar 12 at 7:06
    
@moon.musick - certainly not, I do it all the time. It's just that gnuplot, Postgresql's psql, MySQL's mysql and a ton of other interfaces all do Emacs mode more or less by default. If only Oracle could get sqlplus to do command line editing... no, no. That would be too much to ask of a Major Corporation. They have Trends To Follow! –  Bruce Ediger Mar 12 at 12:56
    
Yeah, most often inputrc does the thing for shell tools, but then I catch myself wondering for half a second why j does not scroll down in, say, Mendeley Desktop after switching to it from terminal, and they were asked for vim bindings too several times. Can't cover everything and have a consistent environment, unfortunately. –  moon.musick Mar 12 at 21:18

I use both gVim and Emacs well enough to be productive, though I am expert in neither. One thing I can say with certainty is that Vim and gVim run faster on my Windows 7 laptop (which I have to use at work). Emacs, on the Windows box, has an odd habit of "pausing" for up to minute and becoming unresponsive, even while continuing to accept keyboard input, before spitting out everything accumulated in the keyboard buffer in a rush. This does not happen in Mac OS or Linux. Nonetheless I find myself using Vim or gVim most of the time on all platforms just so I don't have to stop and think about which editor I am using and adjust. That said, in a purely *nix environment, I would probably stay with Emacs because I find modeless editing slightly more natural.

Bottom line: in my opinion both editors are powerful enough to handle any and all text editing needs. The choice should be based on practical considerations (like platform implementation specifics), and working style.

share|improve this answer

Main difference between Emacs and Vim is ergonomic. There is carpal tunnel syndrome, CTS, as you know. Emacs is very "danger" if you have CTS and provocates CTS. Vim - not, you can read about this difference in many places. For ex., in Vim you can edit text only with one finger. In Emacs - you can not :)

share|improve this answer
2  
It’s not even proven that CTS is actually related to keyboard use. Though superficially plausible, there are links showing that CTS is actually caused genetically more than anything else. So while it may still help to type less when you already have CTS, I don’t think there is any evidence to say that one editor causes CTS more than another. –  Konrad Rudolph Jul 2 '12 at 19:04

I use vi/nvi (NOT vim) because it is simple and unobtrusive.

vim loves beeps so much its harder and somewhat unobvious to be shut off. I had to physically remove the internal pc speaker before eventually found that buried-ref about how to do it :)

set vb t_vb=

Also I don't use syntax coloring, gray over black to me is the most beautiful.

And maybe I'm too stupid to figure out that tangled-multi-key-pressed emacs way the only three key combination I remember is CTRL-ALT-DEL.

share|improve this answer

protected by Michael Mrozek Sep 29 '12 at 18:04

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.