GNU Emacs: Creeping Featurism Is a Strength

The title of this weeks chapter states that creeping featurism, which is widely regarded as a problem with many software projects can also be a strength. Before reading this chapter I have not really had any experience with emacs. Sure I have installed and opened it, but quickly retreated to the safety of my beloved VIM due to the unfamiliar interface. I have observed that a higher percentage of the really good developers I have met use emacs than developers in general. I don't know if this means anything though other than the fact that it is an advanced tool for advanced people.

The chapter talks about the architecture of emacs describing it as a MVC architecture. The internals of emacs consist of a set of character buffers that are its models. The buffer data are flat sets of characters, but they also supports various features such as overlays and text properties. This part of emacs also contains a display engine that will detect changes to the buffers and merge these to larger update operations that is communicated to the views. The views then takes these "update events" and displays them as efficiently as they can. This observer-like design is a powerful feature of emacs in that it allows the controllers to not have to worry about how the text they produce/update will be displayed. This essentially breaks a many to many relationship and greatly reduces complexity.

The final part of this architecture is what is described as the core of emacs, namely its controller layer. This layer, consisting of very thick controllers, I guess is the biggest part of emacs by far as it essentially contains all of its application functionality. Where the model is written in C, the controller layer is written in emacs Lisp that is interpreted by emacs. As such emacs is really an abstract machine for processing and displaying text that provides a set of functionality such as buffer management, etc. And emacs lisp is a domain specific programming language with hooks into the underlying model allowing it to consume and produce text and properties.

By developing such a framework for producing features they have created a very strong separation between the internals of emacs (its model and interpreter) and its feature controllers. This means people can add new features without introducing new complexity in the core much in the same way that people can write new applications for the x86 processor without adding complexity to it. This separation, strongly enforced by the interpreter, is the key to it not blowing up under the weight of all its features.

While reading the chapter I was thinking about how this relates to the chapter on adaptive object models. Both are about platforms that implement interpreters for special-purpose rules. In emacs case the rules are functions written in a turing-complete language that operates on text. In adaptive object models such as the ones described in that paper I guess one tend to use less complex business rules than that, but the basic concept seems to me the same in that both provide abstract machines for implementing rules instead of the rules themselves.

Finally, one thing I was curious about is how things like syntax highlighting is handled. One way would be to have the views format the text, but this would place a lot of application logic in the views. The way I guess they do it is to use the text properties to describe the different colors of the text and then have a set of controllers read buffers and produce these properties. This of course would mean that the views must understand these properties, but a certain amount of view logic is unavoidable.