Ergonomic Emacs Keybindings

I just spent three days trying out Xah Lee’s ErgoEmacs – ergonomic Emacs keybindings – and I’ve been impressed. Easier in terms of typing, given that the most frequent commands are defined as Alt-. (where “.” is a single key) instead of as Ctrl- (or worse, Ctrl-C Ctrl-.). Thus “Emacs pinkie” is less likely, since the thumbs are more heavily used on the the Alt keys instead of the pinkies working the Ctrl keys.

Setup is trivial. Just grab the zip file, unzip it into ~/.emacs.d, and add the following to your ~/.emacs file:

(setenv "ERGOEMACS_KEYBOARD_LAYOUT" "us") ; US

;; load ErgoEmacs keybinding
(load "~/.emacs.d/ergoemacs-keybindings-5.3.9/ergoemacs-mode")

;; turn on minor mode ergoemacs-mode
(ergoemacs-mode 1)

Among the first things to do is, at least if you’re running with the default Gnome keyboard shortcuts, is to disable alt-space from raising the menu within terminals (at least, this is the case for gnome-terminal). To do this, change or disable the shortcut via Preferences > Keyboard Shortcuts > Desktop > Show the panel’s main menu. Select that, hit backspace, and it should now read “Disabled”.

ErgoEmacs is actually two modules in one: it first is, as its name says, a more ergonomically friendly version of Emacs, where commonly-used commands have easy-to-type shortcuts, that is, with the use of Alt instead of Ctrl, and by favoring the keys in the center of the keyboard, as opposed to [, ], \, ~, etc.

The second module is that it uses the now-standard (for lack of a better word) editor shortcuts for operations such as opening files, copy, cut, and paste, which is much more intuitive and consistent with other editors.

I like much of it, but have some issues. I agree that the default Emacs keybindings and behavior are difficult, overwhelming and inconsistent with other editors, and should be updated. However, as with the Qwerty keyboard, we’re essentially stuck, by “we” I mean Unix-based programmers using Emacs, especially the most experienced ones. ErgoEmacs seems designed best for people experienced with mainstream editors such as Notepad and TextMate.

Emacs is so second-nature to me that I don’t consciously know some (most?) of the key shortcuts. If you’re like that, chances are that ErgoEmacs will force you to think about the shortcuts, causing cognitive friction that will interrupt your flow. If you have RSI issues, then you’re more likely to benefit, although as a programmer, I’m typing the oddball keys ([], {}, ()) so much that it is not significant to me to have the less frequently used commands a bit easier to type. (I’d never thought of that before, but it’s another reason to like Ruby: fewer special characters, since for example blocks are delimited with “begin” and “end” instead of “{” and “}”.)

The tipping point for me against ErgoEmacs is that my shell, Z shell, does not have the equivalent shortcuts, so I would essentially have to remember two separate (and conflicting) sets of commands.

That brings me to my final point: I dislike that ErgoEmacs provides no bridge or transition period for going from standard Emacs to ErgoEmacs. I’ve read that one can provide hints (in the same way that vanilla Emacs suggests shortcuts after you’ve executed a command via the traditional (M-x whatever). Having this with out-of-the-box ErgoEmacs would have been nice.

That said, I like the principle behind ErgoEmacs, and I’ll certainly be taking some ideas from it. On that note, I’ve finally posted my Emacs environment, 16 years of cruft and all, on GitHub here. I’ll be actively refining it over the next few weeks, and intend to have it up to date and stable by the end of January.

Timelessness of Quality

I’ve been rereading Hackers and Painters, by Paul Graham, and his chapter on Lisp was especially interesting, given that I’ve been working on expanding my Emacs knowledge and further refining my environment.

The connection between Lisp and Emacs? In this sense, they both became the standard-bearer for their field (programming languages, text editors), and reached that point very soon after the inception of the field. Each of them was so far ahead of the others that even decades later, one could argue that neither Lisp nor Emacs has been matched. If anything, progress in the fields has just been that the mainstream (meaning, widely accepted) products are more and more like Lisp and Emacs.

This doesn’t seem atypical, that there is this quantum leap early in the field. Among guitarists the Gibson Les Paul and Fender Stratocaster are probably the two most popular electric guitars, even a half century after their initial release in the late 1950s, when the electric guitar originated. In my non-expert vantage point I don’t perceive a fundamental difference (as in performance and function, not appearance) between the newest guitars now and the original Strat and Les Paul.

As Graham does, the same argument could be made for Ruby and Lisp, that of “modern” programming languages, Ruby is one of the closest to Lisp in terms of functionality (although its form is somewhat different). About Emacs, I don’t know what other text editor could be considered close, but it seems that Emacs is the most imitated – for example, it seems that the Eclipse editor is much closer to Emacs in behavior than it is to, say, vi. (On that note: is any other text editor similar to vi?)

It seems that the cycle is somewhat like this: the field originates, there are a few competing lead products, one dominates clearly, then there are relatively few imitators for the next decade or two (or more). After a while, the imitators become better and more like the original, to the point that they are essentially just re-badging it.

I’ve tried several times to really learn Lisp in the past, but had difficulty hurdling the syntax, probably in part because of my background in C, Perl, C++ and Java. But having now read of the similarities between Lisp and Ruby, I’m eager to see the difference in my perspective as I go through the excellent Emacs and Emacs Lisp tutorials at Xah Lee’s Emacs Blog).

Project pvn

pvn, here on GitHub, is my newest project, a front-end to the Subversion command-line program “svn”. This program will unite my various svn programs, such as svndelta, and my various scripts.

I’ve been building it from scratch, with a core of commands wrapping those in svn, and new commands. At this point the only more-or-less fully working subcommand is log, which extends svn log to use “relative revisions” (explained below), and displays colorized output. I plan to add the functionality so that a user can set the format and colors for log output.

What is probably the most innovative functionality in pvn is that revisions may be “relative”, meaning that +N is the Nth revision, and -N is the Nth revision before the most recent one. In a large project, revision numbers can get into the six and seven digits, and it’s much easier to think of “the latest checkin I did”, as opposed to “my checkin with revision 317127”.

I don’t have a timeline, but my goal is to have the functionality of the log and diff subcommands implemented by the end of the year.