A personal view of GNU Emacs

While working at the Boston studio of Irrational Games in 2003, I heard something about Emacs being able to run a command shell inside of it, and was quite intrigued. Meanwhile my Palm Zire was rapidly becoming inadequate as my responsibilities grew—I needed a better way to organize my work, and fast. Once I read about Planner I decided to give Emacs a try.

I was really impressed! Not only did I have a working todo-list and note-taking system, it even left behind a set of concise daily reports to show what you accomplished. Before long I was using Emacs for all of my work: correspondence (quite important when your supervisor lives in another hemisphere), remote system management, website development and maintenance, scheduling, and the preparation of numerous documents—everything from brief memoranda and itineraries, to much longer contract bid specifications and project status reports.

Eventually I ran into a dead-end somewhere, and wrote a 10-line Emacs Lisp function to bridge the gap. I was impressed that I could just make it do what i wanted. Soon I was routinely writing my own Lisp code, and using eev-mode to automate, organize, and document all the different things I had to do with shells on various machines. Discussions with Eduardo Ochs and with the Emacs IRC community added immeasurably to my knowledge. I fell in love with the Emacs Lisp language and realized that I was excited about programming for the first time in years.

In 2005 I left Irrational to pursue other opportunities, and started working full-time on what would become known as the KarmaPod—my GNU/Linux-based portable recording studio and computer music research workstation.

I wanted the Pod to look, act, and feel like Emacs. This meant carefully choosing and configuring applications to work seamlessly with Emacs, and involved a lot of false starts. Eventually I developed a standard color theme and coordinated my fvwm setup to match it. I installed Snd—a fully-featured multichannel audio editor and mixer loosely modeled after Emacs, and fully extensible with Scheme. For automated multitrack audio processing and live recording, I installed ecasound. This is a very useful, if a bit awkward, multipurpose command-line audio program. It includes Delysid's ecasound.el so it can be fully controlled from Emacs. (I have built some experimental tools on top of ecasound.el: see Ecaspace.)

But much work was still ahead in making this UI vision into a reality. For months, Eduardo Ochs and I discussed the user interface design of the Pod. During these intense IRC sessions I learned a lot about Lisp programming, software design, software documentation processes, and programming aesthetics—probably more than I had learned in my undergraduate program. Most of all I have been taught higher-level programming techniques, and as a result I believe I have become an order of magnitude more productive as a programmer. So I owe Eduardo my eternal thanks.

By the time I quit my job, I had gotten a bit tired of Planner and wanted to try something new. I came across a strange and little-known Japanese mode called howm and was intrigued by its radically different approach. Like Planner, it combined wiki concepts with note-taking, task list, appointments, and links to various content types. Unlike Planner, the markup was very free-structured, and could be combined with any major mode. You could embed TODO items within lisp source code comments, for example. Howm's "goto links" and "come-from links" could be used to categorize notes and to navigate from one to another. Soon I discovered that I could freely mix eev-mode and howm-mode content into other files. I began to feel that some untapped potential lay deep within Emacs, ready to be teased out by a cowboy programmer.

There was very little English-language documentation available for Howm, so I wrote a Howm Tutorial. But before long I ran into some things that made Howm seem less palatable to me. It isn't suitable for structuring longer documents, and there are no export options (such as HTML.) I wrote a draft of an HTMLizer but soon gave up on Howm entirely.

Then I found org-mode, which is a much better fit for my needs. It uses outline-mode to structure and navigate large projects. It has a simple markup syntax supporting bullets, emphasis, hyperlinks, tables, images, and multiple nested headings. Org-mode's workflow management is sophisticated and can be configured for a variety of work situations and personal styles. Project documents are easily exported to HTML. In fact, a given project's webpage, TODO-list, and research notes can all be maintained in the same .org file and published automatically to the web.

I wrote a program called org-publish to automate the updates to my website. It keeps track of modification times of my publishable files, and converts/uploads pending changes upon request. After Carsten Dominik decided to include it in the org-mode distribution, I signed my Emacs copyright assignment papers with the Free Software Foundation and have since become a proud Emacs developer.

They say you never truly understand an idea until you have had to teach it to someone else. It forces you to grasp the concept and put it into your own words. Recently I have had some experience teaching Emacs to other people, including some who are not computer programmers.

• my init.el
• my recipes for downloading and building GNU Emacs from CVS, downloading and installing various other emacs packages
• my ColorThemes
• home page for GNU Emacs

CLOSED: 2006-05-07 Sun 18:38

CLOSED: 2006-05-07 Sun 14:51

CLOSED: 2006-05-06 Sat 21:09

CLOSED: 2006-05-04 Thu 15:34

CLOSED: 2006-04-27 Thu 19:04
SCHEDULED: 2006-04-27 Thu

• The first line of each documentation must be a self-contained sentence because some commands only display that first line.

After the line you explain what is necessary:

• For variables, what the variable holds, what are valid values for it, what do the values mean. If the variable is one that Users are allowed to change, the documentation string should be understandable by a normal user.
• For normal functions, explain the function arguments (using UPPER CASE for the variable names. Also document what the return value of the function is.
• For interactive commands it is basically like functions, but keep in mind that this is the information normal user look up. Function documentation can assume that the reader reads lisp, for commands it is nice if that is not required.