Pre-testing Emacs 22
At least, the officially-released version of Emacs has stood still. Meanwhile, the development community has been busy working toward Emacs 22. Richard Stallman - who still keeps a firm hand on the direction of Emacs development - has never been inclined to give dates for upcoming software releases. So, after five years, we still don't know when Emacs 22 might be released, but we do know that it is getting closer: the first pre-test release of GNU Emacs 22 is, at long last, available. The project has reached the point where the desired features are in place and stabilization is an increasingly high priority.
Your editor grabbed the pre-test release, and has been working with it for a couple of days - it is being used to type this article. At first blush, the new version of Emacs does not look all that much different. The windows look the same, most of the keystrokes are the same, and your editor has not yet encountered any elisp code which fails to work properly - even the brutal elisp hacks which connect Emacs to the LWN article database work without changes. The Emacs developers have seemingly done a good job of maintaining compatibility over five years of development.
The new GNU Emacs does feel a little faster and more responsive, somehow. There are also various little things one notices over time. For example, a command to open a new file generates a prompt like this:
![[modeline]](https://static.lwn.net/images/ns/grumpy/modeline1.png){kind=small}
The prompt includes the directory where the file is expected to be found. Emacs has always allowed the user to simply type a new path, starting with "/" or "~"; the new version, however, makes the resulting action (ignoring the previous path in the prompt) clear:
![[modeline]](https://static.lwn.net/images/ns/grumpy/modeline2.png){kind=small}
It's little things like this which make an interface more pleasant and easy to use. On the other hand, the new policy of requiring a keystroke to get past the "one component of the GNU/Linux operating system" screen is obnoxious - but this behavior can be disabled.
Of course, there's plenty of bigger things in this new release, once one goes looking. Support for internationalization and encodings has been significantly improved. Also improved is window system support: Emacs now understands mouse wheels without special instructions and will do the right thing when files are "dropped" into it. One can turn on "focus follows mouse" behavior even within Emacs frames. The addition of an IRC client would have been useful, but this is Emacs, so they added two different ones. There is a new "calc" mode which is truly scary in the things it can do. "Org mode" is a Tomboy-like notes-taking application, but with an order of magnitude more features. There is a built-in spreadsheet with all the usual features and some unusual ones - like the ability to enter cell formulas in Lisp. Flymake mode performs on-the-fly syntax checking of source code as it is being entered. There is a new, fancier printing mechanism built into the editor. And so on. The current NEWS file gives a lengthy overview of the changes - though somehow it omits the important addition of a Tetris game.
When LWN first posted the pre-test announcement, the result was an immediate mini-flamewar on the merits of Emacs relative to vi. One can only expect that, as the Emacs 22 release gets closer and draws more attention, we will see more of this sort of debate. Your editor must confess that he has never quite understood what motivates these battles; one person's choice of editor should not really be a problem for somebody else.
More to the point, though, your editor is one of those rare, strange people who actually uses both editors over the course of a normal day. They both have their strengths and weaknesses, and each fits your editor's working style at different times.
- vi is fast, in a number of ways. It starts quickly, which is nice
when a quick job needs to be done. It is likely to be the most
keystroke-efficient editor around, especially once one gets the hang
of how the movement and editing commands combine. Files can be edited
in vi using relatively straightforward keys and no strange modifier
combinations.
On the other hand, vi has an inherently modal interface, which is considered to be bad human factors in general and which trips up every user sooner or later. It is deeply line-oriented at its core, though some more recent versions have done a better job of hiding that fact. And vi simply lacks a number of more advanced features; it was never meant to contain mail clients, RSS readers, calendars, or psychoanalysis programs. Recent work to add some of these features to vi feel misplaced, like putting a trailer hitch onto a two-seater sports car.
- Emacs is an interactive user interface development environment which
happens to be very good at editing text. Many years of effort have
gone into using this environment to develop editing tools of great
power. Emacs has long had a high level of integration with tools like
compilers, debuggers, text formatters, etc. which still does not exist
in vi. There can be great joy in having a full editor environment
available when dealing with mail or debugging a program. Emacs, when
well configured and understood, can be a great productivity aid.
But, then, Emacs is a vast monster of a program - though it has been rapidly out-bloated by current desktop tools. Somebody who has been an expert Emacs user for many years will still only know a fraction of its capabilities; it can be frustrating to know that, somewhere in there, lurks just the feature needed to get a job done - but to not be able to find it. The wrong key sequence can occasionally lead to hallucinogenic results, to the point that there is a special command ("view-lossage") to answer those "how the hell did I make it do that?" questions. Even some relatively trivial customizations require typing in Lisp code, which, for some strange reason, not everybody wants to learn how to do.
There is also an entire branch in the physical therapy field dedicated to the treatment of little-finger injuries caused by excessive Emacs use.
The end result of all the above is that your editor tends to use Emacs for most day-to-day work, including the editing of articles and source code. When working as root and editing system configuration files, however, he tends to switch to vi. And, seeing advantages in both tools, your editor sees no real reason for intense discussions about which is better.
Such discussions will certainly come about, however, as the Emacs
development cycle heads toward its conclusion. The new release seems
unlikely to tempt many vi users to make a switch, but Emacs users will have
something to celebrate. After all this time, there will be a significant
update for this venerable tool (the first thing released by the GNU
project). Just don't ask RMS when to expect it.