While Emacs remains my primary text editor, there are times when starting a full Emacs session with tons of packages is simply too slow, especially on a terminal window, and when the task at hand is simply to make a few lines of changes in a configuration file.
Yes, I do know about the handy
-q command-line option, which prevents the
init.el file from being loaded, thereby ensuring a sub-second initialization of Emacs, or the
emacsclient route (which I have enabled, and do use), but sometimes it is just more convenient to have a fast editor that has the Emacs feel, without the bloat. And for a text nerd such as myself, it is also a matter of curiosity to try out other editors once in a while.
Emacs actually has had a rich history of variants and alternate implementations, with XEmacs being one of more well known forks. On the Mac OS X, Aquamacs has remained a good option for a number of years. A more comprehensive list is available on the Wikipedia page for Emacs.
Both XEmacs and Aquamacs are forked from, or derivatives of GNU Emacs, which is probably the most used Emacs these days. However, other light-weight Emacs-like editors still exist, and I have been trying out three of these, vile, zile, and jmacs. On the Mac, these are available via Mac Ports, on Fink, and possibly on Homebrew.
vile is an interesting blend of Emacs and vi, and provides the modal commands from vi, but also has many of the window management features of Emacs (including similar Emacs key-bindings). It is really more of a vi variant, but the window management does make it very handy, though it does not support the text objects and other vi extensions as Vim does.
jmacs (the Joe editor’s Emacs emulation) seems to be the most feature rich, and the syntax highlighting seems to be best of the lot.
Then there is zile, yet another Emacs clone that I am beginning to love for being lightweight, and having the most Emacs-like behavior. For simple text entry, zile seems to feel to be the fastest—though in reality—all three editors start up pretty fast.
In the end, while I still end up with using
Emacs/emacsclient for most of my editing (after all, I do keep a Emacs session running most of the time like the true faithful), it is still fun to dabble with these editors, if for nothing else than to marvel at the core Emacs editing experience that these micro-editors can provide, in sub-Megabyte packages (
vile = 680K,
zile = 251K,
joe = 440K on my machine).
As an experiment, I have recently started using Vim as my primary text editor. While I have been an Emacs aficionado for a very, very long time – clocking in at almost 16 years – Vim is something that I have always been curious about, and tinkered with from time to time, while ending up going back to Emacs. This time however, I intend to stick around for a while, and try to get a feel of the Zen of Vim.
The experience with Vim has been rather pleasant so far. While configuration is definitely a must (just like Emacs), out of the box experience is not bare bones either. In fact, the default settings are rather good, and one can get a lot of mileage from the vanilla setup.
The USP of Vim is that it is first and foremost a text editor, and does not attempt to be THE kitchen sink. In other words, its core focus is to provide the best and most functions to manipulate text; it is not to provide a universal platform where one of the applications happens to be an editor.
The Editing Model
The very first experience the user gets on launching Vim is that it is a modal editor, with distinct modes for entering text, and editing it.
This is in stark contrast to most other editors, which provide the editing functions via other mechanisms, such as menus or key chords (à la Emacs). While this might seem odd at first glance, it is definitely a key component of Vim’s power, and arguably its success as a text editor.
In addition, the second key distinguishing factor of Vim is that its editing is based on a “noun-adjective-count-movement-verb” model of editing. Nearly every editing command is a sequence of one or more of these primitives, where the intent of the edit operation is usually fully mapped to the encoding offered by various combinations of these primitives.
As an example, to move 5 lines down, and then 3 words forward, to delete the next two words, the following “primitive encoding” can be used:
5j 3w 2de
While this is a rather trivial example, it illustrates a key principle of using Vim – the editing model is based on MOVEMENT and MANIPULATION, explicitly and succinctly made via the modal key-chords which apply the same basic foundational model at all scales.
To a large extent, this underlying pair is what the user usually is thinking about, when an editing operation is being thought of. The primitives are just the vocabulary to tell Vim to execute the intent.
The movement itself can be further separated into raw movements (i.e., lines and characters), or be semantic oriented (words, sentences, paragraphs, functions, etc.) This can sometimes be further refined using “adjectives” such as “begin”, “end”, “between”, or “surrounded”. In addition, the count represents multiples of the movement unit being specified, and allows velocity of the movement to be increased significantly.
The verb is of course where the “real action” happens. In a general sense, every verb is really a “change” verb, with specializations of “delete”, “replace”, “convert”, etc.
In essence, the core feature set of Vim (and certainly its spiritual ancestor – Vi) can be adequately expressed by the core model described above.
However, a basic feature does not make a competent editor. This requires other user comforts such as multi-file edits, windowing mechanisms (including split windows), language syntax, external tool integration (spell checks, compilers, shell interaction), extensive customization to fit the user’s need, an usable in-built help system, and many more such features that make regular usage comfortable and transparent. And Vim does have all of these in abundance, with parity with Emacs in most of these areas in terms of feature completeness, and power.
The feeling I get from using Vim is really about efficiency and focus, while Emacs seems to exude more a sense of power. Both can be frustrating at times, often from over-abundance of features than anything else, and hidden functionality that takes years to internalize before returns are gained.
Vim and Emacs are both excellent editors, and share a lot in common. The complexity, feature-richness, and the high learning curve are the ones that stand out the most. Also, the vibrant community around both editors is a shared characteristic.
Editor wars aside, both are very competent and complex pieces of software, and will serve the user well, provided an investment is made in learning the unique interfaces that both exhibit.
As for me, I do not anticipate leaving the Emacs bandwagon any time soon — especially with significant investments now in the Orgmode work-flow that I have built up over the past few years. However, I do see Vim as another pro-tool in my toolbox, which is definitely going to get a lot more love and use in the days ahead.