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 0session 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).
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.
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.
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.
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
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.
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.
Asymptotic learning curve
Both Vim and Emacs have a lot of features, and you will keep discovering new ones after years of use.
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.
Some Features
- Multi-byte Characters
Both Vim and Emacs support multi-byte characters, although for a long time, international characters were only available through plugins for emacs.
- Extensibility
Both Vim and Emacs support plugins that enhance their functionality. Emacs can be extended in elisp, while Vim has its own internal scripting language called [VimScript] and supports use of other programming languages for plugin development.
Vim can also be extended on the fly by using the command mode. The command mode allows configuration options to be set, functions to be defined, and macros to be made. In fact, configuration files for Vim are just commands that can be input through the command mode.
Emacs advocates often point to the extreme customizability of the editor as its crowning achievement. Emacs could be said to be written in its own extension language (strictly speaking, the reverse is true: lisp supports run-time modifications of the running instance, and modifications automatically work and are incorporated if they are syntactically correct). As a result, Emacs can be extended on the fly by redefining built-in elisp functions, either by typing the new definition into Emacs or by loading elisp files. Groups of related changes are typically called “modes”, and can be easily configured to be automatically used for particular types of files(buffers), say for different programming languages or frameworks such as “lisp mode” or “Ruby mode” or “Rails mode”. Since these can directly modify even core behaviours of Emacs, or automatically format or colorize text and add standard template or “boilerplate” text such as function declarations and closures, users typically find Emacs to be far more customisable to their particular requirements than is Vim. In particular, Emacs users who spend most of their time in a single “environment” or task-type find themselves able to precisely customise their normal environment to their preferred workflow in any respect important to them. Much of Emacs’s devoted following stems from this ability.
- Graphical Interface
Both Vim and Emacs have graphical user interfaces. While the graphical interface provides menus for both applications, virtually all menu items are just different ways to handle a shortcut command or quick configuration. There is almost nothing that can be done on the graphical user interface that cannot be done through direct commands and shortcut keys for both editors.
Emacs uses XDisplay or gtk2 for its GUI. Vim is able to use many other GUI libraries, such as gtk, gtk2, gnome, gnome2, motif, athena, neXtaw, photon, carbon.
It should be noted that Emacs can display graphics and different fonts in a window. GVim is limited to one font that must be fixed width.
- Buffer Tabs
Both Vim and Emacs have support for buffer tabs in both the CLI and the GUI.
- Misc
Vim is often available on servers, to be used through ssh.
- Associated Operating System and License
GNU Emacs is licensed with the GNU GPL, and is much more commonly associated with the GNU/Linux operating system, given the fact that it is a part of the GNU project. Vim’s license is defined as charityware, although the author states it is GPL compatible. Vim was also originally based on vi, which was first written by Bill Joy, and although Vim is used by many GNU/Linux users, it could therefore be considered native to the BSDs; a maintained “nvi” variant is the default text editor for FreeBSD.
Overview of differences
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.
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.
That’s it. If You Have any Question just Comment it 🙂
