What Makes Emacs Unique, Laundry-list Style

What really makes Emacs unique is the fact that it is a text editor with an embedded Turing-complete programming language. It’s infinitely customisable, and so allows you to arrange it according to what makes you personally productive.

But this post is not about philosophy. I’m dedicating this post to a laundry list of features that make Emacs better than any text editor/IDE/administration tool out there. (Some of them can be found in the Emacs guided tour.) I’ll try keep this post updated as I think of more features.

Update 09 Jul 2007:

• Regular expression builder

As you type a regular expression, every matching substring in the current buffer gets highlighted, and each submatch of the regular expression is highlighted in a different color. To use: M-x re-builder.

• Keyboard macros

These allow the recording of a sequence of keystrokes to be replayed later. Anything possible to do in Emacs is possible through the keyboard, so this feature is quite powerful. It’s especially useful for tedious reformatting tasks.

To use: C-x (, perform the actions you want to record, then C-x ) to stop. To run the keyboard macro at any time, use C-x e.

• Unloseable undo

In any editor I’ve ever used, if you Undo several times, then type some, the stuff you undid cannot be redone. That portion of the undo history is lost. In Emacs, this is not the case: it is always possible to get back to any previous state of the buffer of text.

• Interactive search-and-replace across directories

Say you need to rename most occurrences of a pattern, but not some. You won’t be able to use a perl -pi or find+sed since you need to exclude certain occurrences. What you need is an interactive process that lets you look at each match, and decide whether to replace.

To use: look here.

Update 28 Jun 2008: I recently ran across a top ten list of emacs features. It’s quite useful.

Next Language?

Recently I’ve been thinking, “I’ve done the Lisp thing. Also, SML and OCaml. What’s the next language I could learn that will change the way I think about programming?”

Erlang seems pretty cool. Really inexpensive parallelism and built-in capability for distributed process on a bunch of machines. Pattern matching. Built-in tuples. All good things… but it’s dynamically typed. The benefit of strong typing (every expression has a type, inferred or declared, at compile-time; and types are checked) is well known. I have taken this to heart, and programmer friends of mine know I get very testy when someone threatens my Hindley and Milner.

Haskell, on the other hand, has a magnificently expressive type system. It has dependent types, generalised algebraic data types, and type classes, all which make for a fruitful compilation step and contribute to code confidence. Type classes in particular provide operator overloading⁰ in a type-safe way. But if languages are schoolteachers, Haskell is a pushover: it has non-strict semantics. This property is less-accurately¹, but more commonly known as laziness.

I don’t like this aspect of Haskell. It seems to make it hard to reason about the complexity of an algorithm. “Am I accumulating stack?” While it might be quick to code something correctly, coding correctly and efficiently is a less obvious process for me.

Ignoring these options, however: who’s to say I’ve really understood Lisp, SML, or OCaml? Some would have it that it takes longer than a few years to really become an expert in any reasonably general-purpose language. I like this, and so my current plan is to stick it out for a while with OCaml (education permitting).

Currently I’m exercising my OCaml-fu by implementing a parallel Sudoku solver in Jocaml. Jocaml is an extension of OCaml that implements the join calculus, a formal language for asynchronous communicating processes. Basically, instead of just wrapping some system threads library, Jocaml provides orthogonal primitives to describe fundamental building-blocks of processes and how they communicate. As a bonus, the whole thing is formal, so you could conceivably prove theorems about a program written in Jocaml, because there is a mathematical theory underlying all the asynchronous bits.

^[0]Also called ad-hoc polymorphism, though I’ve yet to discover why.

^[1]In my vocabulary, strict semantics is a language property meaning that evaluating an expression involves first completely evaluating its subexpressions. It follows, then, that a language has non-strict semantics when it does not have strict semantics.

One consequence of non-strict semantics is the possibility of embedding non-terminating expressions in a terminating program. For example, suppose use-first-argument is a binary function that does exactly what it says, namely does something with its first argument only, ignoring its second. In a strict language (e.g. everything, mostly), where stands for an expression whose evaluation never terminates, the function call use-first-argument (X, ) will never terminate. In a non-strict language (Haskell), that code fragment will return whatever use-first-argument returns. If the expression’s value is never needed, it is never computed, and hence the infinite recursion is never triggered.

To return to the point, laziness is the property of a program or data structure — a value can be lazily computed by saving intermediate results until the final result is manually requested, at which point evaluation occurs. Laziness can be written into Java, or OCaml, or any language. One example is a common pattern in OO system implementation: set the values of member variables the first time they are accessed, rather than upon initialisation of the class.