This is the second article in my ongoing series about text editing software. Text editing software being here defined as programs that let you edit text, contain special features for editing programming code, and are not especially designed for just one language or language family.

In the first article, we looked at Vim, the program I use to edit text most frequently. For this one, we’re going to be exploring an editor I don’t use quite so much – one that’s not really in the generally accepted pantheon of programmers’ text editors – but one that’s got some really interesting and useful ideas about workflow.

Acme

In the early 90s, Rob Pike (most known in recent years for the creation of Google’s Go language) was working with some others at Bell Labs to create a radically new evolution of the Unix operating system. This project was dubbed Plan 9 from Bell Labs after the Ed Wood film.

The ideas behind Plan 9 were to modernise Unix for a graphical environment where the user had access to the mouse, and to carry some elements of Unix’s design philosophy to their logical conclusions. Plan 9 is made up of small, single-purpose applications which communicate with each other via text streams, and everything is a file.

Plan 9 came with two text editing programs: sam and acme. Sam is a line-editing program, similar to [ed](«»), and Acme can be considered Plan 9’s version of vi or emacs. Unlike those programs, however, Acme was built from the start as a graphical program with mouse support.

Here we have to be careful of the connotations of “graphical” and “mouse support”, though. Acme is not a slick, swishy program with lots of animations, and nor does it have mountains of clickable menus and buttons for everything. Though you won’t be able to run Acme’s interface in a terminal, its interface is very much a textual one. And as for the mouse, well, Acme is at its most effective when used with a three-button mouse – and that’s three buttons, not two buttons and a trackwheel.¹

Using Acme, you spend most of your time clicking on bits of text. Clicking on words in the program’s top bars and within the main editing buffers will perform different actions depending on whether you use the left, right or middle button. You can also drag different coloured selections of text with each of your mouse buttons (most programs only let you do this with the left button). But that’s not all! Acme’s mouse interface makes heavy use of chording, a concept usually reserved for the keyboard. If you click on a word or drag a selection while holding in both the left and middle button at the same time, yet another distinct action is performed. And the same goes for the other button combinations. Here’s a handy diagram:

This interface is quite exotic and difficult to get used to, and it doesn’t help that the modern mouse trackwheel makes a pretty poor substitute for the middle button Acme was designed for. But it’s quite fun once you get the hang of it, and it makes it possible to perform long strings of text editing options without once touching the keyboard (or navigating a drop-down menu).

So the mouse controls are interesting, but they serve only as a pointer to what I think is the main power of Acme. Take a look at that diagram above. Note the action performed by the middle mouse button: execute.

The official webpage for Acme bears the subtitle “A User Interface for Programmers”, and that’s telling. Acme is not just a text editor: it is also a command shell. To execute a command, you type it into a text buffer and middle-click it. If the command is more than one word, you use the middle mouse button to drag a selection over it and then release to execute. The output of your command will appear in a +Errors buffer: if one does not yet exist, it will be created.

What’s more, the +Errors buffer, despite some special qualities, is just as editable as any other, and so outputs from commands can be slightly altered into new commands and then run.

But Acme is not just a text editor and command shell: it is also a file browser. Right-click the name of a directory, and another window pops up to display the directory’s contents, which can be right-clicked in turn to either open further directories or files for editing. Needless to say, these directory readouts can also be arbitrarily modified to facilitate execution, say by prepending a command to a particularly long file name and then executing the whole thing.

All text in the Acme window is editable, both in the yellow buffers to the blue bars on the top. The blue bars come with a number of convenient and oft-used commands by default. While these can be deleted, they regenerate later, creating a sense that the blue bars are editable in order to be expanded with frequent commands of the user’s own rather than entirely rewritten.

This all leads to a very powerful, and, once you get used to the unorthodox mouse usage, intuitive way of editing files, navigating the file system, and executing scripts and commands. You can mold your interface according to changing needs with such little effort that you do so without thinking, and you’ve got the whole operating system to play with.

In Acme’s native environment, that operating system was Plan 9, where, if you’ll recall, everything was a file. This has some interesting implications for Acme’s structure²: each window the user has open is represented as a directory on the filesystem, containing the following files:

acme/.../addr
acme/.../body
acme/.../ctl
acme/.../data
acme/.../errors
acme/.../event
acme/.../tag
acme/.../xdata

Each of these files has a distinct purpose. For example:

• acme/.../ctl can be written to execute new commands in the window.
• acme/.../tag maps to the contents of the window’s blue bar (formally known as the tag).
• acme/.../data holds the contents of the main window.

Most of these files can be written to in order to change Acme’s behaviour, which means they can be written to programmatically to change Acme’s behaviour, which means Acme can be extended using any programming language capable of writing text to a file. This is in line with Plan 9’s strong adherence to the Unix Philosophy: the idea that complex systems are built out of small, simple programs, each doing a single thing to the best of its ability, communicating with other small, simple programs through the universal medium of text.

But what’s the catch?

After all that gushing praise, you might be wonder why, if Acme’s so great, is it so little-known and little-used? Why have you never seen it before? And what, if anything, would stop a reasonable programmer from switching over to it for their daily editing tasks?

Well, for one thing, no-one has an old-fashioned three-button mouse anymore. Additionally, your hardcore Emacs and Vim set are generally quite against using even a modern, two-button-and-scrollwhell mouse for any part of text editing work. But even getting past those two hurdles, Acme remains difficult in ways that severely limit its adoption; many of these stem from the rigidity of Rob Pike’s personal vision for the program.

Pike read somewhere that the distinctive shades of yellow and blue that colour Acme are the best colours for people to stare at all day. Maybe this is true. But what it means in practice is that Acme comes in yellow and blue, and only in yellow and blue. To get another colour scheme, you’ll have to change the source code and recompile the thing: there’s no theming Acme like you would with GVim or Sublime Text.

Additionally, while you can use the left and right arrow keys to move your text cursor across lines, you can’t use the up and down arrow keys to move between lines. “That,” Pike seems to say from behind the yellow curtain, “is a task for the mouse!”

Other things that may turn most programmers away from Acme include its lack of syntax highlighting³, the way words you type will appear in the window or tag you mouse cursor is hovering over, and the default (but changeable) preference for using a variable width font.

Most of these things were specifically included as part of the design philosophy of Acme – users should use the mouse for navigation, it is not the job of the editor to highlight syntax, etc, etc – and while there’s an undeniable elegance to the program’s design as a result, a lot of practicalities and alternatives are completely missing. If you use Acme, you have to use it the Acme way: although its everything-is-a-file architecture gives it incredible extensibility in many senses, it has none of the built in customisation features of Vim or Emacs that allow you to, say, change your keyboard shortcuts.

The original Unix clone of Acme, named Wily, alters this status quo a little – in Wily you’re allowed to move your text cursor between lines with the up and down arrow keys, but Wily is also missing a number of Acme’s features and was deprecated following the creation of Plan 9 from User Space, a port of Acme and other Plan 9 utilities to Unix-alikes, and the version I’ve been using for all the above screenshots.⁴

Final thoughts

I don’t use Acme for day-to-day editing for most of the reasons stated above. It’s worth experimenting with because of the way it shatters preconceptions about:

• graphical interfaces.
• mouse controls.
• the distinction between editor, shell and file browser.

You can emulate an Acme +Errors buffer in Vim to some degree with Vimshell (a plugin recommended in the first post in this series) and a couple of keybindings. My .vimrc:

" Open VimShell
nnoremap <leader>vs :set noautochdir<CR>:VimShellPop<CR>

" VimShell keymappings
let g:vimshell_no_default_keymappings=1
autocmd FileType vimshell imap <buffer> <cr> <Plug>(vimshell_enter)
vnoremap <leader>x :VimShellSendString<cr>
nnoremap <leader>x V:VimShellSendString<cr>

This allows me to open a Vimshell split with <leader>vs and execute either the current selection or the current line with <leader>x. It’s fairly rudimentary and doesn’t involve the mouse, but I’ve found it a very useful setup, and one I wouldn’t even have known I wanted without trying Acme. To quote my previous post:

And that’s why I’m writing this series: be­cause by trying different editors, I hope to get an idea of what sort of features are out there, and how badly I never knew I needed them.

Bibliography

• Rob Pike’s academic paper on Acme
• JLOUIS Ramblings: Acme as an editor
• Mostly Maths: Extensibility in the Acme text editor
• Dev and Such: Let’s Try Acme (10 part series)