412

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.

10

15 Answers 15

453

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. Nevertheless, a new fork of vim, Neovim has proved to have fixed this and implemented other various bug-fixes not implemented in stock vim.

15
  • 38
    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). Jul 29, 2011 at 12:36
  • 10
    This made me feel small... Dec 25, 2011 at 4:10
  • 16
    @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, 2012 at 10:45
  • 6
    @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). Aug 22, 2013 at 12:18
  • 5
    @MichaelHampton You must be young then. In 1985, it was Eight Megabytes. By now I suppose it should be Eight thousand Megabytes, except that nobody notices Emacs's memory usage since it's less than one browser tab. Oct 17, 2014 at 11:24
282

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

13
  • 9
    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? Aug 22, 2010 at 7:06
  • 13
    @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 Aug 22, 2010 at 16:25
  • 4
    Would somebody please explain what does emacs graph, given above, means? How to interpret it? Oct 2, 2010 at 16:51
  • 31
    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.)
    – ocodo
    Nov 16, 2010 at 4:20
  • 15
    +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, 2011 at 9:36
87

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.

15
  • 1
    I'm quite a vim user, but I often find it difficult to use vi, most likely because of the END key (vim supports it, but vi doesn't, or at least doesn't by default)
    – phunehehe
    Aug 22, 2010 at 13:49
  • 27
    @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. Aug 22, 2010 at 16:41
  • 5
    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, 2010 at 6:22
  • 12
    @phunehehe I don't use esc. I use ctrl+[ it does the same thing ;) Aug 29, 2010 at 14:57
  • 8
    +1 for Gaurav's comment. Vi works excellent for emergency editing of config files over a crappy 3G connection on a slow cell phone.
    – LawrenceC
    Jan 11, 2011 at 3:57
27

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.

2
  • 1
    One comment about the line "the instincts you develop working with vim won't cross over to other programs": The line "set editing-mode vi" can be added to an ~/.inputrc file (on Linux system which support it). This enables vi-style syntax for entering text in programs using readline for stdin, such as the bash shell itself. There can be (sometimes surprisingly) a fair amount of broader applicability to the editing instincts that one develops using vim. Apr 6, 2015 at 10:46
  • Fortunately, there's many people with that problem, and they have built extensions for lots of programs to make them more vim-like. Aug 16, 2018 at 7:37
24

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.

4
  • 32
    "Emacs would make a great operating system, if only it had a text editor worth a shit." -- I was reminded of this quote. Nov 27, 2011 at 6:24
  • @amphetamachine I don't get the quote. Does it mean to demean emacs-the-text-editor?
    – tshepang
    Apr 27, 2013 at 8:21
  • It does mean to, though I usually hear it more tongue-in-cheek that bitingly.
    – Cody Poll
    Feb 12, 2015 at 18:05
  • As for the editors themselves, I find vim easier to edit text with, but I have to hand customizability to emacs. Vimscript just can't stand up to a lisp.
    – Cody Poll
    Feb 12, 2015 at 18:06
20

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 Occupational Overuse Syndrome (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.

6
  • I enjoyed reading your answer, but I miss the deciding factor. What made you switch from emacs to vim?
    – Erik B
    Aug 8, 2013 at 8:33
  • It was just organic - plus vim's keyboard macros work really well. Aug 8, 2013 at 9:46
  • 1
    Damn, as a younger programmer, the ergonomics argument is very appealing. This might just have settled my choice to go and learn VI and VIm instead of Emacs.
    – Didier A.
    Jun 4, 2015 at 22:31
  • @DidierA. Don't forget to check Spacemacs - Emacs with VIM key bindings. It really is best of both worlds. Feb 22, 2022 at 10:47
  • I went and learned Vim, and then went back to Spacemacs, and actually went back to its holy mode. Since I program mostly in Lisp now, I didn't find the modal and line based editing of VI that great.
    – Didier A.
    Mar 27, 2022 at 20:32
17

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 OS X 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.

10

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.

2
  • 12
    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. Sep 2, 2012 at 19:46
  • 1
    It's worth noting that if you like modal editing, Emacs has good support for it through evil-mode - emacswiki.org/emacs/Evil Jun 15, 2016 at 12:26
9

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.

4
  • 1
    set -o vi in bash or zsh is not too hard to run (or put in an rc file) in my opinion. Mar 12, 2014 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!
    – user732
    Mar 12, 2014 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. Mar 12, 2014 at 21:18
  • 4
    @BruceEdiger I highly doubt that developers of mysql(1), psql(1), gnuplot(1), also python(1), perlconsole(1), lftp(1), smbclient(1) and indeed lots of interactive programs were concerned about keybindings for line-editing. All of these software just use GNU Readline, and default mode for GNU Readline is (unsurprisingly) GNU Emacs-like. set editing-mode vi in your ~/.inputrc and voila – all these tools have vi-like keybindings. Jan 18, 2015 at 3:18
9

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 distribution. 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.

1
  • 8
    I sometimes wonder whether this says more about Lisp or about Emacs, and whether that is good or bad... Oct 26, 2010 at 23:29
8

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.

7

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.

3

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 :)

1
  • 3
    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. Jul 2, 2012 at 19:04
-2

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.

-5

"What are the pros and cons of Vim and Emacs?" - ha!

I'll mostly leave the pros to others.

The cons of both of these are that they are both old school. I've used probably 50 different editors over the years from Basic line editors, to super fast assembly coded editors (VEDIT for one), to fancy GUI editors, some better than others. I've even written my own special editor called ForthStar and adapted it to edit a tree of btrieve leaves, with multiple indexes for powerful searching, like to instantly find the last leaves I just edited, or to quickly find code components, or leaf parents or children.

I think both vi and emacs are more religion than muscle. The creative minds that built them have largely moved on, and the new support lacks the courage and skill to re-invent them.

Yes Emacs can do a lot, but it's slowed by lisp, a beautiful and now largely obsolete language.

Both are stuck in difficult keyboard layouts. Emacs could adjust to the user a bit, at a minimum by recognizing that there is an Alt key rather than the antique Meta. And like WordStar recognize that keeping C-A C-B straight from C-A B when speed typing is not worth the distinction. Better to just simply have one that is fired by either key combo. Yes you can alter key bindings, but then what a mess you have later.

Vi is clever, but lacks powerful search and replace like in Notepad++ which shows you what it's found, lets you expand it out and selectively apply it, in color, just to mention one innovation.

Almost any other GUI ap these days allows zoom with the mouse wheel. Emacs GUI doesn't seem to get this to work. And where's the nice greeking like what Kate has?

My favorite keyboard layout over the years was Wordstar's cursor diamond. At least it was easy to learn and made sense immediately. The one I hated the most was WordPerfect which increased complexity and seems to have been based somewhat on emacs.

Let's face it most of the world has GUI these days. And like it or not text editors are somewhat stuck in their age.

I think it would be better to have a universal editor that could easily switch between emacs, vi, wordstar, or whatever key layouts, and without loosing the more powerful commands it has to offer. Real programmers have to use a variety of editing tools. Why not have an editor which meets our needs to get work done rather than to force us into their way of doing things?

3
  • Since the question asked for both pros and cons, this does not answer the question. As far as I can see, it only mentions how other editors ar better than both Vi and Emacs.
    – Kusalananda
    Apr 1, 2018 at 6:25
  • Any answers are okay for a question, until they answer the question and they are essentially different as the previous ones. "Looks Ok".
    – peterh
    Apr 1, 2018 at 12:51
  • The Q clearly asks for the cons. And I mention some pros. Apr 2, 2018 at 16:52

Not the answer you're looking for? Browse other questions tagged .