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.
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.
Sign up to join this communityI 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.
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:
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
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.
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)
Aug 22, 2010 at 13:49
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
vim
:)
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.
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.
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.
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.
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.
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.
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
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!
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
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
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.
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.
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.
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 :)
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.
"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?
M-! emacs RET
It's like search google for "google"