e file:’0,$’

e file

In Oberon, such a collection would be called a tool and would consist of a set of entry points in a module and a menu-like piece of text containing representative commands that may be edited to suit and executed. There is, in fact, a tool called Edit in Oberon. To provide related functionality, Acme exploits the directory and file structure of the underlying system, rather than the module structure of the language; this fits well with Plan 9’s file-oriented philosophy. Such tools are central to the working of Oberon but they are less used in Acme, at least so far. The main reason is probably that Acme’s program interface permits an external program to remain executing in the background, providing its own commands as needed (for example, the Reply command in the mail program); Oberon uses tools to implement such services because its must invoke a fresh program for each command. Also, Acme’s better integration allows more basic functions to be handled internally; the right mouse button covers a lot of the basic utility of the editing tools in Oberon. Nonetheless, as more applications are written for Acme, many are sure to take this Oberon tool-like form.

Comparison with other systems

Acme’s immediate ancestor is Help [Pike92], an experimental system written a few years ago as a first try at exploring some of Oberon’s ideas in an existing operating system. Besides much better engineering, Acme’s advances over Help include the actions of the right button (Help had nothing comparable), the ability to connect long-running programs to the user interface (Help had no analog of the event file), and the small but important change to split command output into windows labeled with the directory in which the commands run.

Most of Acme’s style, however, derives from the user interface and window system of Oberon [Wirt89, Reis91]. Oberon includes a programming language and operating system, which Acme instead borrows from an existing system, Plan 9. When I first saw Oberon, in 1988, I was struck by the simplicity of its user interface, particularly its lack of menus and its elegant use of multiple mouse buttons. The system seemed restrictive, though—single process, single language, no networking, event-driven programming—and failed to follow through on some of its own ideas. For example, the middle mouse button had to be pointed accurately and the right button was essentially unused. Acme does follow through: to the basic idea planted by Oberon, it adds the ability to run on different operating systems and hardware, connection to existing applications including interactive ones such as shells and debuggers, support for multiple processes, the right mouse button’s features, the default actions and context-dependent properties of execution and searching, and a host of little touches such as moving the mouse cursor that make the system more pleasant. At the moment, though, Oberon does have one distinct advantage: it incorporates graphical programs well into its model, an issue Acme has not yet faced.