There and Back Again: My Journey to (and From) Emacs

Jason Madden — Fri, 01 Jun 2018 21:26:07 GMT

This is the story of how I started using Emacs, switched away to vi, and then switched back to Emacs years later.

(This post is part of a series.)

Contents

In The Beginning

Flash back with me, if you will. Picture it, Sicily, 1939...no, wait, that's The Golden Girls. Picture it, rural Oklahoma, 1997-8. All of my computing experience had been with DOS, Windows 3.x and 95 (at home), and MacOS 6 and 7 (at school and locked down). ("Operating systems not known for their advanced editors", he says in his best Johnny impression. [1]) But I was hungry for more, and after talking with a friend from the local bank about their minicomputer running some variant of Unix [2], I was intrigued enough to take the plunge.

I bought a book on Linux specifically to get the CD included in the back, and converted my family's computer to dual-boot between Windows 95R2 and a stripped down RedHat Linux 5 (I think). With limited available documentation, and no Internet access [3], what simple editing I did was with the default, beginner-friendly editor, most likely pico or nano.

Times Grow Turbulent

Skip forward another six months or so. I'm now at OSSM, Oklahoma's residential high school, located in the hustle and bustle of Oklahoma City near the state capital. OSSM's prime real estate meant that it had a direct connection to Oklahoma's Internet backbone, and 100Mbps Ethernet was available in the dorm rooms.

I'm now dual-booting Windows 98 and RedHat 6, and taking my first computer science courses. To do homework assignments, I needed a C compiler and editor. I could go to the computer lab and use their Windows-based IDE (Borland C), but there was no way to install that on the computer in my dorm room. But wait, my RedHat partition had a C compiler. All I needed now was a C editor.

I used the fabulous Internet access to research [4] "best programming editor." The answer I found was Emacs, so I happily set about learning Emacs. Most likely I used XEmacs for its better graphical support—I mean, keyboards are great and all, but X11 is where it's at.

GNOSSM

A well-loved SPARCstation 20. (Photo by Caroline Ford.)

The aforementioned computer lab had a collection of exotic hardware running exotic Unix operating systems:

Personal DECstation 5000/25 running Ultrix 4.3 and later NetBSD 1.42
SPARCStation LX running Solaris 2.4
SPARCStation 20 (dual processors!) running Solaris 2.6

The OSSM network administrators were gracious enough to allow most administration of these machines to be handled by the students. A user group referred to as "GNOSSM" soon formed around these machines.

Unlike RedHat 6, these machines had no (or extremely limited) graphical administration tools. If you wanted to make changes to a configuration (for example, we wanted to share accounts across all of them using NIS), you had to edit text files.

But there was a problem: not all of these machines had Emacs! They didn't even all have pico! (And let's not even talk about trying to install new software on all of them. Have you seen the old Solaris package manager?) On the machines that did have Emacs, it was far too slow to start for the impatience of youth.

You see, Emacs was considered to be a large, heavyweight editor. Disk space and installation media size were factors. Plus, there may have been licensing concerns for the commercial Unix vendors.

Lowest Common Denominator

There was one editor available on all these machines, as well as Linux [5]: vi. It was available [6], it was fast, and ... it was completely foreign. The concept of editing "modes," where different single keys do different things depending on invisible state, was completely different than Emacs's chorded key binding system. Rather than continue learning Emacs and also learning a whole new way of doing things, it was easiest just to drop Emacs. After all, vi turned out to be a decent programmer's editor too!

The Status Quo

And that's where things largely remained for the next decade. I soldiered on with vi as my Unix text editor of choice for personal and school projects as well as system administration tasks. I developed a small customization file for it (~/.vimrc) of about 150 lines, along with language customizations for the types of files I edited most frequently [7].

I was working with a large, distributed team that did most development in Java and had standardized on the Eclipse IDE, so most of my professional editing was done in that tool.

Lisp Changes Everything

In 2007, I began developing the Gozer workflow system whose central feature was a custom Lisp dialect that ran on the Java virtual machine in order to interoperate with the existing Java code. The core interpreter was implemented in Java, but the majority of the standard library for Gozer was implemented in Gozer's Lisp dialect.

Lisp's simple textual structure demands a powerful editor. I was unsatisfied with what was available for Eclipse and what was available for vi. Yet by this point, I was so invested in those platforms that I was reluctant to make any changes to my editing habits, and I continued to use them for my Lisp code.

SLIME

Some of the features that SLIME provides.

Lisp, like Python, is an interactive language, usually featuring a REPL where a programmer can input short code snippets and see printed results. Gozer originally had a REPL based on telnet: a programmer would start the Gozer interpreter which in turn would listen on a socket, and then in a different console window would telnet in to the Gozer process, where they could type commands and see textual output. This worked, but was cumbersome, and didn't offer much in the way of introspection.

One of the things every language needs is a debugger. The Eclipse IDE had a very rich debugger for Java programs, capable of setting breakpoints and inspecting objects. I wanted something like that for Gozer, but didn't have the time to implement both the necessary support in Gozer as well as the UI in Eclipse.

Meanwhile, the Gozer Lisp dialect was evolving to implement a large subset of the Common Lisp standard. This meant that I needed to be able to write and test programs in a Common Lisp implementation (SBCL) in order to compare them to what Gozer was doing. For a debugger, REPL and IDE, SBCL used SLIME.

SLIME, the Superior Lisp Interaction Mode for Emacs, runs in Emacs. To use it, I would have to start using Emacs again. I grumbled about this to anyone who would listen, but two factors changed my mind.

The first was the existence of Paredit, a way to structurally edit Lisp in Emacs that takes advantage of Lisp's unique and regular form. Together with the existing Emacs Lisp editing support, this provided by far the best way to edit Lisp that I had yet seen.

The second was the fact that SLIME was (mostly) cleanly separated into two parts: the frontend that ran in Emacs, and a backend called "swank" that ran in the Lisp process. This separation is how SLIME supported almost a dozen widely different Lisp implementations. With just a little bit of work to implement the swank protocol, Gozer could have a full featured IDE, REPL, and debugger [8]! This put it over the top, and I moved all of my Lisp work into Emacs.

Journey's End?

Editing this post in Emacs.

Today, I do almost all of my personal and professional editing in Emacs. I've found Emacs's customizability [10], power, and broad language support to be a good fit for my needs.

Python code is edited using the standard python.el mode, together with the excellent elpy IDE extension.
Posts for this site use rst.el to edit reStructuredText.
Everything is wrapped up in CEDET and ECB.

The transition wasn't as painful as I feared. I enjoy the fact that on macOS, GUI text fields have many of the most common Emacs keybindings enabled by default (e.g., Ctrl-A takes you to the beginning of the line and Ctrl-E to the end) [9]. Console applications that use the readline library for text entry (including most shells like bash and the Python REPL) also use these keys.

In case you were worried, rest assured that I haven't abandoned vi. I still type view by default on the console to quickly look at files, especially programming language files.

Footnotes

[1]	Which is not very good.

[2]	It was a BSD. Or possibly a SVR4.3.

[3]	You try configuring PPP and a Winmodem on RedHat 5.

[4]	With an early version of Google, launched in 1998.

[5]	On Linux, it would have been Vim, a vastly expanded version of the original vi.

[6]	Having been created by Bill Joy as part of the original BSD releases. Joy later moved to Sun, creators of Solaris, and vi followed. It's also standardized by POSIX.

[7]	Those file types were C, HTML, Java, LaTeX, Objective-C, Perl, PHP and SQL.

[8]	The nascent Cusp Eclipse plugin also used swank to communicate between the GUI in Eclispe and the Lisp implementation. By implementing the protocol, I could offer a full IDE to those that would use Emacs, and still offer some basic support for those that wanted to use Eclipse.

[9]	With just a little work, you can get many more keybindings.

[10]	I have about 1400 lines of Emacs Lisp code to customize Emacs to my preferences, and I have dozens of third-party extensions installed.

Editor Wars: Violent Delights Have Violent Ends

Jason Madden — Fri, 01 Jun 2018 21:15:38 GMT

As developers, one of the most important tools in our toolkits is our editor. Looking around the office, you'll find a wide variety of editors in use, everything from editors with long pedigrees to the most recently developed editor boasting the technology du jour.

The choice of editor can be a very personal thing. While we have no interest in starting or escalating the actual editor war, we thought it would be interesting to survey the office and collect some stories about editors and the people who use them in this ongoing (sporadic) series.

There and Back Again: My Journey to (and From) Emacs — Jason Madden (2018-06-01)

Jason Madden (An ongoing series about our most important tool, our editors.)

There and Back Again: My Journey to (and From) Emacs

Editor Wars: Violent Delights Have Violent Ends