1 .HTML "Acme: A User Interface for Programmers
6 .de FG \" start figure caption: .FG filename.ps verticalsize
14 .de fg \" end figure caption (yes, it is clumsy)
24 .html - <center><a href="\\$1.gif"><img src="\\$1.gif" /></a></center>
33 Acme: A User Interface for Programmers
36 .I rob@plan9.bell-labs.com
42 Originally appeared in
44 Proc. of the Winter 1994 USENIX Conf.,
49 A hybrid of window system, shell, and editor, Acme gives text-oriented
50 applications a clean, expressive, and consistent style of interaction.
51 Traditional window systems support interactive client programs and offer libraries of
52 pre-defined operations such as pop-up menus
53 and buttons to promote a consistent
54 user interface among the clients.
55 Acme instead provides its clients with a fixed user interface and
56 simple conventions to encourage its uniform use.
57 Clients access the facilities of Acme through a file system interface;
58 Acme is in part a file server that exports device-like files that may be
59 manipulated to access and control the contents of its windows.
60 Written in a concurrent programming language,
61 Acme is structured as a set of communicating processes that neatly subdivide
62 the various aspects of its tasks: display management, input, file server, and so on.
64 Acme attaches distinct functions to the three mouse buttons:
65 the left selects text;
66 the middle executes textual commands;
67 and the right combines context search and file opening
68 functions to integrate the various applications and files in
71 Acme works well enough to have developed
72 a community that uses it exclusively.
73 Although Acme discourages the traditional style of interaction
74 based on typescript windows\(emteletypes\(emits
75 users find Acme's other services render
79 History and motivation
81 The usual typescript style of interaction with
82 Unix and its relatives is an old one.
83 The typescript\(eman intermingling of textual commands and their
84 output\(emoriginates with the scrolls of paper on teletypes.
85 The advent of windowed terminals has given each user what
86 amounts to an array of teletypes, a limited and unimaginative
87 use of the powers of bitmap displays and mice.
88 Systems like the Macintosh
89 that do involve the mouse as an integral part of the interaction
90 are geared towards general users, not experts, and certainly
92 Software developers, at least on time-sharing systems, have been left behind.
94 Figure 1. A small Acme screen\(emnormally it runs on a larger display\(emdemonstrating
95 some of the details discussed in the text.
96 The right column contains some guide files,
97 a mailbox presented by Acme's mail program,
98 the columnated display of files in Acme's own source directory,
99 a couple of windows from the OED browser,
101 and an error window showing diagnostics from a compilation.
102 The left column holds a couple of source files
106 another debugger window displaying a stack trace,
107 and a third source file
110 was opened from the debugger by clicking the right mouse button
111 on a line in the stack window;
112 the mouse cursor landed on the offending line of
114 after a click on the compiler message.
117 Some programs have mouse-based editing of
118 text files and typescripts;
119 ones I have built include
128 These have put the programmer's mouse to some productive work,
129 but not wholeheartedly. Even experienced users of these programs
130 often retype text that could be grabbed with the mouse,
131 partly because the menu-driven interface is imperfect
132 and partly because the various pieces are not well enough integrated.
134 Other programs\(emEMACS [Stal93] is the prime example\(emoffer a high
135 degree of integration but with a user interface built around the
136 ideas of cursor-addressed terminals that date from the 1970's.
137 They are still keyboard-intensive and
140 The most ambitious attempt to face these issues was the Cedar
141 system, developed at Xerox [Swei86].
142 It combined a new programming language, compilers,
143 window system, even microcode\(ema complete system\(emto
144 construct a productive, highly
145 integrated and interactive environment
146 for experienced users of compiled languages.
147 Although successful internally, the system was so large
148 and so tied to specific hardware that it never fledged.
150 Cedar was, however, the major inspiration for Oberon [Wirt89],
151 a system of similar scope but much smaller scale.
152 Through careful selection of Cedar's ideas, Oberon shows
153 that its lessons can be applied to a small, coherent system
154 that can run efficiently on modest hardware.
155 In fact, Oberon probably
156 errs too far towards simplicity: a single-process system
157 with weak networking, it seems an architectural throwback.
159 Acme is a new program,
160 a combined window system, editor, and shell,
162 some of the ideas distilled by Oberon.
163 Where Oberon uses objects and modules within a programming language (also called Oberon),
164 Acme uses files and commands within an existing operating system (Plan 9).
165 Unlike Oberon, Acme does not yet have support for graphical output, just text.
166 At least for now, the work on Acme has concentrated on
167 producing the smoothest user interface possible for a programmer
170 The rest of this paper describes Acme's interface,
171 explains how programs can access it,
172 compares it to existing systems,
173 and finally presents some unusual aspects of its implementation.
178 Figure 2. An Acme window showing a section of code.
179 The upper line of text is the tag containing the file name,
180 relevant commands, and a scratch area (right of the vertical bar);
181 the lower portion of the window is the
182 body, or contents, of the file.
183 Here the scratch area contains a command for the middle button
185 and a word to search for with the right button
188 clicked the right button on
190 and Acme has searched for the word, highlighted it,
191 and moved the mouse cursor there. The file has been modified:
192 the center of the layout box is black and the command
196 Acme windows are arrayed in columns (Figure 1) and are used more
197 dynamically than in an environment like X Windows or
200 The system frequently creates them automatically and the user
201 can order a new one with a single mouse button click.
202 The initial placement of a new window is determined
203 automatically, but the user may move an existing window anywhere
204 by clicking or dragging a
206 in the upper left corner of
209 Acme windows have two parts: a
211 holding a single line of text,
214 holding zero or more lines (Figure 2).
215 The body typically contains an image of a file being edited
216 or the editable output of a
217 program, analogous to an
219 window. The tag contains
220 the name of the window
221 (usually the name of the associated
222 file or directory), some built-in commands, and a scratch area to hold arbitrary text.
223 If a window represents a directory, the name in the tag ends with
224 a slash and the body contains a list of the names of the files
226 Finally, each non-empty body holds a scroll bar at the left of the text.
228 Each column of windows also has a layout box and a tag.
229 The tag has no special meaning, although Acme pre-loads it with a few
231 There is also a tag across the whole display, also loaded with
232 helpful commands and a list of active processes started
235 Typing with the keyboard and selecting with the left button are as in
236 many other systems, including the Macintosh,
239 The middle and right buttons are used, somewhat like the left button,
240 to `sweep' text, but the indicated text is treated in a way
241 that depends on the text's location\(em\f2context\f1\(emas well as its content.
242 This context, based on the directory of the file containing the text,
243 is a central component of Acme's style of interaction.
245 Acme has no single notion of `current directory'.
246 Instead, every command, file name,
247 action, and so on is interpreted or executed in the directory named by the
248 tag of the window containing the command. For example, the string
254 will be interpreted as the file name
256 if such a file exists.
258 Throughout Acme, the middle mouse button is used to execute commands
259 and the right mouse button is used to locate and select files and text.
260 Even when there are no true files on which to operate\(emfor example
261 when editing mail messages\(emAcme and its applications use
262 consistent extensions of these basic functions.
263 This idea is as vital to Acme as icons are to the Macintosh.
265 The middle button executes commands: text swept with the button
266 pressed is underlined; when the button is released, the underline is
267 removed and the indicated text is executed.
268 A modest number of commands are recognized as built-ins: words like
274 functions performed directly by Acme.
275 These words often appear in tags to make them always available,
276 but the tags are not menus: any text anywhere in Acme may be a command.
277 For example, in the tag or body of any window one may type
279 select it with the left button, use the middle button to execute it,
280 and watch it disappear again.
282 If the middle button indicates a command that is not recognized as a built-in,
283 it is executed in the directory
284 named by the tag of the window holding the text.
285 Also, the file to be executed is searched for first in that directory.
286 Standard input is connected to
288 but standard and error outputs are connected to an Acme window,
289 created if needed, called
290 \f2dir\f(CW/+Errors\f1 where
292 is the directory of the window.
293 (Programs that need interactive input use a different interface, described below.)
294 A typical use of this is to type
298 in the scratch area in the tag of a C source window, say
299 .CW /sys/src/cmd/sam/regexp.c ,
301 Output, including compiler errors, appears in the window labeled
302 .CW /sys/src/cmd/sam/+Errors ,
303 so file names in the output are associated with the windows and directory
307 command remains in the tag, serving as a sort of menu item for the associated
310 Like the middle button, the right button is used to indicate text by sweeping it out.
311 The indicated text is not a command, however, but the argument of a generalized
313 If the text, perhaps after appending it to the directory of the window containing it,
314 is the name of an existing file, Acme creates a new window to hold the file
315 and reads it in. It then moves the mouse cursor to that window. If the file is
316 already loaded into Acme, the mouse motion happens but no new window is made.
317 For example, indicating the string
323 in a window on the file
324 .CW /sys/src/cmd/sam/regexp.c
326 .CW /sys/src/cmd/sam/sam.h .
328 If the file name is followed immediately by a colon and a legal address in
329 Sam notation (for example a line number or a regular expression delimited in
330 slashes or a comma-separated compound of such addresses), Acme highlights
331 the target of that address in the file and places the mouse there. One may jump to
334 by indicating with the right button the text
336 If the file is not already open, Acme loads it.
337 If the file name is null, for example if the indicated string is
339 the file is assumed to be that of the window containing the string.
340 Such strings, when typed and evaluated in the tag of a window, amount to
343 If the indicated text is not the name of an existing file, it is taken to be literal
344 text and is searched for in the body of the window containing the text, highlighting
345 the result as if it were the result of a context search.
347 For the rare occasion when a file name
349 just text to search for, it can be selected with the left button and used as the
350 argument to a built-in
352 command that always searches for literal text.
354 Nuances and heuristics
356 A user interface should not only provide the necessary functions, it should also
359 In fact, it should almost not be felt at all; when one notices a
360 user interface, one is distracted from the job at hand [Pike88].
361 To approach this invisibility, some of Acme's properties and features
362 are there just to make the others easy to use.
363 Many are based on a fundamental principle of good design:
364 let the machine do the work.
366 Acme tries to avoid needless clicking and typing.
367 There is no `click-to-type', eliminating a button click.
368 There are no pop-up or pull-down menus, eliminating the mouse action needed to
370 The overall design is intended to make text on the screen useful without
371 copying or retyping; the ways in which this happens involve
372 the combination of many aspects of the interface.
374 Acme tiles its windows and places them automatically
375 to avoid asking the user to place and arrange them.
376 For this policy to succeed, the automatic placement must behave well enough
377 that the user is usually content with the location of a new window.
378 The system will never get it right all the time, but in practice most
379 windows are used at least for a while where Acme first places them.
380 There have been several complete rewrites of the
381 heuristics for placing a new window,
382 and with each rewrite the system became
383 noticeably more comfortable. The rules are as follows, although
384 they are still subject to improvement.
385 The window appears in the `active' column, that most recently used for typing or
387 Executing and searching do not affect the choice of active column,
388 so windows of commands and such do not draw new windows towards them,
389 but rather let them form near the targets of their actions.
390 Output (error) windows always appear towards the right, away from
391 edited text, which is typically kept towards the left.
392 Within the column, several competing desires are balanced to decide where
393 and how large the window should be:
394 large blank spaces should be consumed;
395 existing text should remain visible;
396 existing large windows should be divided before small ones;
397 and the window should appear near the one containing the action that caused
400 Acme binds some actions to chords of mouse buttons.
405 so these common operations can be done without
407 Another is a way to apply a command in one window to text (often a file name)
408 in another, avoiding the actions needed to assemble the command textually.
410 Another way Acme avoids the need to move the mouse is instead to move the cursor
411 to where it is likely to be used next. When a new window is made, Acme
412 moves the cursor to the new window; in fact, to the selected text in that window.
413 When the user deletes a newly made window, the cursor is
414 returned to the point it was before the window was made,
415 reducing the irritation of windows that pop up to report annoying errors.
417 When a window is moved, Acme moves the cursor to the layout box in
418 its new place, to permit further adjustment without moving the mouse.
419 For example, when a click of the left mouse button on the layout box grows
420 the window, the cursor moves to the new location of the box so repeated clicks,
421 without moving the mouse, continue to grow it.
423 Another form of assistance the system can offer is to supply precision in
424 pointing the mouse. The best-known form of this is `double-clicking' to
425 select a word rather than carefully sweeping out the entire word.
426 Acme provides this feature, using context to decide whether to select
427 a word, line, quoted string, parenthesized expression, and so on.
428 But Acme takes the idea much further by applying it to execution
432 click, that is, a null selection, with either the middle or right buttons,
433 is expanded automatically to indicate the appropriate text containing
434 the click. What is appropriate depends on the context.
436 For example, to execute a single-word command
439 it is not necessary to sweep the entire word; just clicking the button once with
440 the mouse pointing at the word is sufficient. `Word'
441 means the largest string of likely file name characters surrounding the location
442 of the click: click on a file name, run that program.
443 On the right button, the rules are more complicated because
444 the target of the click might be a file name, file name with address,
445 or just plain text. Acme examines the text near the click to find
447 if it finds one, it checks that it names an existing file (in the directory named in the tag, if the name is relative)
448 and if so, takes that as the result, after extending it with any address
449 that may be present. If there is no file with that name, Acme
450 just takes the largest alphanumeric string under the click.
451 The effect is a natural overloading of the button to refer to plain text as
454 First, though, if the click occurs over the left-button-selected text in the window,
455 that text is taken to be what is selected.
456 This makes it easy to skip through the occurrences of a string in a file: just click
458 on some occurrence of the text in the window (perhaps after typing it in the tag)
459 and click once for each subsequent occurrence. It isn't even necessary to move
460 the mouse between clicks; Acme does that.
461 To turn a complicated command into a sort of menu item, select it:
462 thereafter, clicking the middle button on it will execute the full command.
464 As an extra feature, Acme recognizes file names in angle brackets
466 as names of files in standard directories of include files,
467 making it possible for instance to look at
471 Here's an example to demonstrate how the actions and defaults work together.
473 .CW /sys/src/cmd/sam/regexp.c
475 open and has been edited. We write it (execute
477 in the tag; once the file is written, Acme removes the word from the tag)
480 in the tag. We execute
482 and get some errors, which appear in a new window labeled
483 .CW /sys/src/cmd/sam/+Errors .
484 The cursor moves automatically to that window.
487 main.c:112: incompatible types on assignment to `pattern'
489 We move the mouse slightly and click the right button
490 at the left of the error message; Acme
491 makes a new window, reads
492 .CW /sys/src/cmd/main.c
493 into it, selects line 112
494 and places the mouse there, right on the offending line.
496 Coupling to existing programs
498 Acme's syntax for file names and addresses makes it easy for other programs
499 to connect automatically to Acme's capabilities. For example, the output of
501 grep -n variable *.[ch]
503 can be used to help Acme step through the occurrences of a variable in a program;
504 every line of output is potentially a command to open a file.
505 The file names need not be absolute, either: the output
506 appears in a window labeled with the directory in which
508 was run, from which Acme can derive the full path names.
510 When necessary, we have changed the output of some programs,
511 such as compiler error messages, to match
513 Some might argue that it shouldn't be necessary to change old programs,
514 but sometimes programs need to be updated when systems change,
515 and consistent output benefits people as well as programs.
516 A historical example is the retrofitting of standard error output to the
517 early Unix programs when pipes were invented.
519 Another change was to record full path names in
520 the symbol table of executables, so line numbers reported by the debugger
521 are absolute names that may be used directly by Acme; it's not necessary
522 to run the debugger in the source directory. (This aids debugging
525 A related change was to add lines of the form
527 #pragma src "/sys/src/libregexp"
529 to header files; coupled with Acme's ability to locate a header file,
530 this provides a fast, keyboardless way to get the source associated with a library.
532 Finally, Acme directs the standard output of programs it runs to
533 windows labeled by the directory in which the program is run.
534 Acme's splitting of the
535 output into directory-labeled windows is a small feature that has a major effect:
536 local file names printed by programs can be interpreted directly by Acme.
537 By indirectly coupling the output of programs to the input,
538 it also simplifies the management of software that occupies multiple
541 Coupling to new programs
543 Like many Plan 9 programs,
544 Acme offers a programmable interface to
545 other programs by acting as a file server.
546 The best example of such a file server is the window system
549 which exports files with names such as
554 through which applications may access the I/O capabilities of the windows.
558 set of files for each window and builds a private file name space
559 for the clients running `in' each window;
560 clients in separate windows see distinct files with the same names
563 Acme, like the process file system [PPTTW93], instead associates each
564 window with a directory of files; the files of each window are visible
566 This difference reflects a difference in how the systems are used:
568 tells a client what keyboard and mouse activity has happened in its window;
569 Acme tells a client what changes that activity wrought on any window it asks about.
570 Putting it another way,
572 enables the construction of interactive applications;
573 Acme provides the interaction for applications.
576 Acme's file system is mounted using Plan 9 operations on the directory
579 that root directory appears a directory for each window, numbered with the window's identifier,
580 analogous to a process identifier, for example
582 The window's directory
584 .CW /mnt/acme/27/addr ,
595 files contain the text of the respective parts of the window; they may be
596 read to recover the contents. Data written to these files is appended to the text;
603 files provide random access to the contents of the body.
606 file is written to set a character position within the body; the
608 file may then be read to recover the contents at that position,
609 or written to change them.
611 small and special-purpose enough not to need special treatment.
614 indexes by character position, which is not the same as byte offset
615 in Plan 9's multi-byte character set [Pike93]).
616 The format accepted by the
618 file is exactly the syntax of addresses within the user interface,
619 permitting regular expressions, line numbers, and compound addresses
620 to be specified. For example, to replace the contents of lines 3 through 7,
627 file, then write the replacement text to the
629 file. A zero-length write deletes the addressed text; further writes extend the replacement.
633 may be written with commands to effect actions on the window; for example
638 sets the name in the tag of the window to
640 Other commands allow deleting the window, writing it to a file, and so on.
643 file recovers a fixed-format string containing 5 textual numbers\(emthe window
644 identifier, the number of characters in the tag, the number in the body,
645 and some status information\(emfollowed by the text of the tag, up to a newline.
650 A program reading a window's
652 file is notified of all changes to the text of the window, and
653 is asked to interpret all middle- and right-button actions.
654 The data passed to the program is fixed-format and reports
655 the source of the action (keyboard, mouse, external program, etc.),
656 its location (what was pointed at or modified), and its nature (change,
657 search, execution, etc.).
658 This message, for example,
662 reports that actions of the mouse
664 inserted in the body (capital
668 at character positions 15 through 19; the zero is a flag word.
669 Programs may apply their own interpretations of searching and
670 execution, or may simply reflect the events back to Acme,
671 by writing them back to the
673 file, to have the default interpretation applied.
674 Some examples of these ideas in action are presented below.
676 Notice that changes to the window are reported
677 after the fact; the program is told about them but is not required to act
678 on them. Compare this to a more traditional interface in which a program
679 is told, for example, that a character has been typed on the keyboard and
680 must then display and interpret it.
681 Acme's style stems from the basic model of the system, in which any
682 number of agents\(emthe keyboard, mouse, external programs
688 change the contents of a window.
689 The style is efficient: many programs are content
690 to have Acme do most of the work and act only when the editing is completed.
691 An example is the Acme mail program, which can ignore the changes
692 made to a message being composed
693 and just read its body when asked to send it.
694 A disadvantage is that some traditional ways of working are impossible.
695 For example, there is no way `to turn off echo': characters appear on the
696 screen and are read from there; no agent or buffer stands between
697 the keyboard and the display.
699 There are a couple of other files made available by Acme in its root directory
700 rather than in the directory of each window.
703 holds a list of all window names and numerical identifiers,
704 somewhat analogous to the output of the
706 command for processes.
707 The most important, though, is
709 a directory that makes new windows, similar to the
711 directory in the Plan 9 network devices [Pres93].
712 The act of opening any file in
714 creates a new Acme window; thus the shell command
716 grep -n var *.c > /mnt/acme/new/body
718 places its output in the body of a fresh window.
719 More sophisticated applications may open
721 read it to discover the new window's identifier, and then
722 open the window's other files in the numbered directory.
724 Acme-specific programs
726 Although Acme is in part an attempt to move beyond typescripts,
727 they will probably always have utility.
728 The first program written for Acme was therefore one
729 to run a shell or other traditional interactive application
730 in a window, the Acme analog of
734 has a simple structure:
735 it acts as a two-way intermediary between Acme and the shell,
736 cross-connecting the standard input and output of the shell to the
738 The style of interaction is modeled after
740 [Pike88]: standard output is added to the window at the
742 text typed after the output point
743 is made available on standard input when a newline is typed.
744 After either of these actions, the output point is advanced.
745 This is different from the working of a regular terminal,
746 permitting cut-and-paste editing of an input line until the newline is typed.
747 Arbitrary editing may be done to any text in the window.
748 The implementation of
755 files, is straightforward.
757 needs no code for handling the keyboard and mouse; it just monitors the
758 contents of the window. Nonetheless, it allows Acme's full editing to be
759 applied to shell commands.
760 The division of labor between
766 and the X server demonstrates how much work Acme handles automatically.
768 is implemented by a single source file 560 lines long and has no graphics code.
771 uses the middle and right buttons to connect itself in a consistent way
772 with the rest of Acme.
773 The middle button still executes commands, but in a style more suited
774 to typescripts. Text selected with the middle button is treated as if
775 it had been typed after the output point, much as a similar feature in
779 and therefore causes it to be `executed' by the application running in the window.
780 Right button actions are reflected back to Acme but refer to the appropriate
783 places the name of the current directory in the tag of the window.
784 If the shell is running, a simple shell function replacing the
786 command can maintain the tag as the shell navigates the file system.
787 This means, for example, that a right button click on a file mentioned in an
789 listing opens the file within Acme.
791 Another Acme-specific program is a mail reader that begins by presenting,
792 in a window, a listing of the messages in the user's mailbox, one per line.
793 Here the middle and right button actions are modified to refer to
795 and messages, but the change feels natural.
796 Clicking the right button on a line creates a new window and displays the
797 message there, or, if it's already displayed, moves the mouse to that window.
798 The metaphor is that the mailbox is a directory whose constituent files are messages.
799 The mail program also places some relevant commands in the tag lines of
800 the windows; for example, executing the word
802 in a message's tag creates a new window
803 in which to compose a message to the sender of the original;
806 In such windows, the addressee is just a list of names
807 on the first line of the body, which may be edited to add or change recipients.
808 The program also monitors the mailbox, updating the `directory' as new messages
811 The mail program is as simple as it sounds; all the work of interaction,
812 editing, and management of the display is done by Acme.
814 difficult sections of the 1200
815 lines of code concern honoring the external protocols for managing
816 the mailbox and connecting to
819 One of the things Acme does not provide directly is a facility like
820 Sam's command language to enable actions such as global substitution;
821 within Acme, all editing is done manually.
822 It is easy, though, to write external programs for such tasks.
823 In this, Acme comes closer to the original intent of Oberon:
826 contains a set of tools for repetitive editing and a template
827 or `guide' file that gives examples
829 Acme's editing guide,
830 .CW /acme/edit/guide ,
833 e file | x '/regexp/' | c 'replacement'
834 e file:'0,$' | x '/.*word.*\en/' | p -n
835 e file | pipe command args ...
837 The syntax is reminiscent of Sam's command language, but here the individual
838 one-letter commands are all stand-alone programs connected by pipes.
839 Passed along the pipes are addresses, analogous to structural expressions
843 command, unlike that of Sam, starts the process by generating the address
844 (default dot, the highlighted selection) in the named files.
845 The other commands are as in Sam:
847 prints the addressed text on standard output (the
849 option is analogous to that of
851 useful in combination with the right mouse button);
853 matches a regular expression to the addressed (incoming) text,
854 subdividing the text;
856 replaces the text; and so on. Thus, global substitution throughout a file,
857 which would be expressed in Sam as
859 0,$ x/regexp/ c/replacement/
861 in Acme's editor becomes
863 e 'file:0,$' | x '/regexp/' | c 'replacement'
866 To use the Acme editing commands, open
867 .CW /acme/edit/guide ,
868 use the mouse and keyboard to edit one of the commands to the right form,
869 and execute it with the middle button.
870 Acme's context rules find the appropriate binaries in
874 the effect is to turn
876 into a toolbox containing tools and instructions (the guide file) for their use.
877 In fact, the source for these tools is also there, in the directory
879 This setup allows some control of the file name space for binary programs;
880 not only does it group related programs, it permits the use of common
881 names for uncommon jobs. For example, the single-letter names would
882 be unwise in a directory in everyone's search path; here they are only
883 visible when running editing commands.
886 such a collection would be called a
889 of a set of entry points in a module and a menu-like piece of text containing
890 representative commands that may be edited to suit and executed.
891 There is, in fact, a tool called
894 To provide related functionality,
895 Acme exploits the directory and file structure of the underlying
896 system, rather than the module structure of the language;
897 this fits well with Plan 9's
898 file-oriented philosophy.
899 Such tools are central to the working of Oberon but they are
900 less used in Acme, at least so far.
901 The main reason is probably that Acme's program interface permits
902 an external program to remain executing in the background, providing
903 its own commands as needed (for example, the
905 command in the mail program); Oberon uses tools to
906 implement such services because its must invoke
907 a fresh program for each command.
909 Acme's better integration allows more
910 basic functions to be handled internally; the right mouse button
911 covers a lot of the basic utility of the editing tools in Oberon.
912 Nonetheless, as more applications are written for Acme,
913 many are sure to take this Oberon tool-like form.
915 Comparison with other systems
917 Acme's immediate ancestor is Help [Pike92], an experimental system written
918 a few years ago as a first try at exploring some of Oberon's ideas
919 in an existing operating system.
920 Besides much better engineering, Acme's advances over Help
921 include the actions of the right button (Help had nothing comparable),
922 the ability to connect long-running programs to the user interface
923 (Help had no analog of the
926 and the small but important change to split command output into
927 windows labeled with the directory in which the commands run.
929 Most of Acme's style, however, derives from the user interface and window
930 system of Oberon [Wirt89, Reis91].
931 Oberon includes a programming language and operating system,
932 which Acme instead borrows from an existing system, Plan 9.
933 When I first saw Oberon, in 1988, I was struck by the
934 simplicity of its user interface, particularly its lack of menus
935 and its elegant use of multiple mouse buttons.
936 The system seemed restrictive, though\(emsingle process,
937 single language, no networking, event-driven programming\(emand
938 failed to follow through on some of its own ideas.
939 For example, the middle mouse button had to be pointed accurately and
940 the right button was essentially unused.
941 Acme does follow through:
942 to the basic idea planted by Oberon, it adds
943 the ability to run on different operating systems and hardware,
944 connection to existing applications including
945 interactive ones such as shells and debuggers,
946 support for multiple processes,
947 the right mouse button's features,
948 the default actions and context-dependent properties
949 of execution and searching,
950 and a host of little touches such as moving the mouse cursor that make the system
952 At the moment, though, Oberon does have one distinct advantage: it incorporates
953 graphical programs well into its model, an issue Acme has not yet faced.
955 Acme shares with the Macintosh a desire to use the mouse well and it is
956 worth comparing the results.
957 The mouse on the Macintosh has a single button, so menus are essential
958 and the mouse must frequently move a long way
959 to reach the appropriate function.
960 An indication that this style has trouble is that applications provide
961 keyboard sequences to invoke menu selections and users often prefer them.
962 A deeper comparison is that the Macintosh uses pictures where Acme uses text.
963 In contrast to pictures, text can be edited quickly, created on demand,
964 and fine-tuned to the job at hand; consider adding an option to a command.
965 It is also self-referential; Acme doesn't need menus because any text can be
966 in effect a menu item.
967 The result is that, although a Macintosh screen is certainly prettier and probably
968 more attractive, especially to beginners, an Acme screen is more dynamic
969 and expressive, at least for programmers and experienced users.
971 For its role in the overall system,
972 Acme most resembles EMACS [Stal93].
973 It is tricky to compare Acme to EMACS, though, because there are
974 many versions of EMACS and, since it is fully programmable, EMACS
975 can in principle do anything Acme does.
976 Also, Acme is much younger and therefore has not
977 had the time to acquire as many features.
978 The issue therefore is less what the systems can be programmed to do than
980 The EMACS versions that come closest to Acme's style are those that
981 have been extended to provide a programming environment, usually
982 for a language such as LISP [Alle92, Lucid92].
983 For richness of the existing interface, these EMACS versions are certainly superior to Acme.
984 On the other hand, Acme's interface works equally well already for a variety
985 of languages; for example, one of its most enthusiastic users works almost
986 exclusively in Standard ML, a language nothing like C.
988 Where Acme excels is in the smoothness of its interface.
989 Until recently, EMACS did not support the mouse especially well,
990 and even with the latest version providing features such as `extents'
991 that can be programmed to behave much like Acme commands,
992 many users don't bother to upgrade.
993 Moreover, in the versions that provide extents,
994 most EMACS packages don't take advantage of them.
996 The most important distinction is just that
997 EMACS is fundamentally keyboard-based, while
1000 People who try Acme find it hard to go back to their previous environment.
1001 Acme automates so much that to return to a traditional interface
1002 is to draw attention to the extra work it requires.
1004 Concurrency in the implementation
1006 Acme is about 8,000 lines of code in Alef, a concurrent object-oriented language syntactically similar to C [Alef].
1007 Acme's structure is a set of communicating
1008 processes in a single address space.
1009 One subset of the processes drives the display and user interface,
1010 maintaining the windows; other processes forward mouse and keyboard
1011 activity and implement the file server interface for external programs.
1012 The language and design worked out well;
1013 as explained elsewhere [Pike89, Gans93, Reppy93],
1014 user interfaces built with concurrent systems
1015 can avoid the clumsy
1016 top-level event loop typical of traditional interactive systems.
1018 An example of the benefits of the multi-process style
1019 is the management of the state of open
1020 files held by clients of the file system interface.
1021 The problem is that some I/O requests,
1024 file, may block if no data is available, and the server must
1025 maintain the state of (possibly many) requests until data appears.
1029 a single-process window system written in C, pending requests were queued in
1030 a data structure associated with each window.
1031 After activity in the window that might complete pending I/O,
1032 the data structure was scanned for requests that could now finish.
1033 This structure did not fit well with the rest of the program and, worse,
1034 required meticulous effort
1035 to guarantee correct behavior under all conditions
1036 (consider raw mode, reads of partial lines, deleting a window,
1037 multibyte characters, etc.).
1039 Acme instead creates a new dedicated process
1040 for each I/O request.
1041 This process coordinates with the rest of the system
1042 using Alef's synchronous communication;
1043 its state implicitly encodes the state of
1044 the I/O request and obviates the need for queuing.
1045 The passage of the request through Acme proceeds as follows.
1047 Acme contains a file server process, F, that executes a
1049 system call to receive a Plan 9 file protocol (9P) message from the client [AT&T92].
1050 The client blocks until Acme answers the request.
1051 F communicates with an allocation process, M,
1052 to acquire an object of type
1054 (`executing fid'; fid is a 9P term)
1055 to hold the request.
1056 M sits in a loop (reproduced in Figure 2) waiting for either a request for
1059 or notification that an existing one has finished its task.
1062 is created, an associated process, X,
1066 allocating new ones only when the list is empty.
1067 Thus, there is always a pool of
1069 some executing, some idle.
1073 object contains a channel,
1075 for communication with its process;
1076 the unpacked message; and some associated functions,
1077 mostly corresponding to 9P messages such as
1079 to handle a 9P write request.
1081 The file server process F parses the message to see its nature\(emopen,
1082 close, read, write, etc. Many messages, such as directory
1083 lookups, can be handled immediately; these are responded to directly
1085 by F without invoking the
1087 which is therefore maintained until the next message.
1088 When a message, such as a write to the display, requires the attention
1089 of the main display process and interlocked access to its data structures,
1091 by sending a function pointer on
1093 For example, if the message is a write, F executes
1095 x->c <-= Xfid.write;
1106 process, X, executes a simple loop:
1112 (*<-x->c)(x); /* receive and execute message */
1113 bflush(); /* synchronize bitmap display */
1114 cxfidfree <-= x; /* return to free list */
1119 will wake up with the address of a function to call (here
1121 and execute it; once that completes, it returns itself to the pool of
1122 free processes by sending its address back to the allocator.
1124 Although this sequence may seem complicated, it is just a few lines
1125 of code and is in fact far simpler
1126 than the management of the I/O queues in
1128 The hard work of synchronization is done by the Alef run time system.
1129 Moreover, the code worked the first time, which cannot be said for the code in
1134 Acme provides a general undo facility like that of Sam, permitting
1135 textual changes to be unwound arbitrarily.
1136 The implementation is superior to Sam's, though,
1137 with much higher performance and the ability to `redo' changes.
1140 a multi-pass algorithm that builds
1141 a transcript of changes to be made simultaneously
1142 and then executes them atomically.
1143 This was thought necessary because the elements of a repetitive
1144 command such as a global substitution should all be applied to the same
1145 initial file and implemented simultaneously; forming the complete
1146 transcript before executing any of the changes avoids the
1147 cumbersome management of addresses in a changing file.
1148 Acme, however, doesn't have this problem; global substitution
1149 is controlled externally and may be made incrementally by exploiting
1150 an observation: if the changes are sorted in address order and
1151 executed in reverse, changes will not invalidate the addresses of
1154 Acme therefore avoids the initial transcript. Instead, changes are applied
1155 directly to the file, with an undo transcript recorded in a separate list.
1156 For example, when text is added to a window, it is added directly and a record
1157 of what to delete to restore the state is appended to the undo list.
1158 Each undo action and the file are marked with a sequence number;
1159 actions with the same sequence number are considered a unit
1160 to be undone together.
1161 The invariant state of the structure
1162 is that the last action in the undo list applies to the current state of the file,
1163 even if that action is one of a related set from, for example, a global substitute.
1164 (In Sam, a related set of actions needed to be undone simultaneously.)
1165 To undo an action, pop the last item on the undo list, apply it to the file,
1166 revert it, and append it to a second, redo list.
1167 To redo an action, do the identical operation with the lists interchanged.
1168 The expensive operations occur
1169 only when actually undoing; in normal editing the overhead is minor.
1170 For example, Acme reads files about seven times faster than Sam, partly
1171 because of this improvement and partly because of a cleaner implementation.
1173 Acme uses a temporary file to hold the text, keeping in memory only the
1174 visible portion, and therefore can edit large files comfortably
1175 even on small-memory machines such as laptops.
1179 Acme is still under development.
1180 Some things are simply missing.
1181 For example, Acme should support non-textual graphics, but this is being
1182 deferred until it can be done using a new graphics model being developed
1183 for Plan 9. Also, it is undecided how Acme's style of interaction should best be
1184 extended to graphical applications.
1185 On a smaller scale, although the system feels smooth and comfortable,
1186 work continues to tune the heuristics and
1187 try new ideas for the user interface.
1189 There need to be more programs that use Acme. Browsers for
1190 Usenet and AP News articles, the Oxford English Dictionary, and other
1191 such text sources exist, but more imaginative applications will
1192 be necessary to prove that Acme's approach is viable.
1193 One that has recently been started is an interface to the debugger Acid [Wint94],
1194 although it is still
1195 unclear what form it will ultimately take.
1197 Acme shows that it is possible to make a user interface a stand-alone component
1198 of an interactive environment. By absorbing more of the interactive
1199 functionality than a simple window system, Acme off-loads much of the
1200 computation from its applications, which helps keep them small and
1201 consistent in their interface. Acme can afford to dedicate
1202 considerable effort to making that interface as good as possible; the result
1203 will benefit the entire system.
1205 Acme is complete and useful enough to attract users.
1206 Its comfortable user interface,
1207 the ease with which it handles multiple tasks and
1208 programs in multiple directories,
1209 and its high level of integration
1211 Perhaps most telling,
1212 Acme shows that typescripts may not be the most
1213 productive interface to a time-sharing system.
1217 Howard Trickey, Acme's first user, suffered buggy versions gracefully and made
1218 many helpful suggestions. Chris Fraser provided the necessary insight for the Acme editing
1223 [Alef] P. Winterbottom,
1224 ``Alef Language Reference Manual'',
1226 Plan 9 Programmer's Manual,
1228 AT&T Bell Laboratories,
1231 revised in this volume.
1235 Allegro Common Lisp user Guide, Vol 2,
1237 Chapter 14, "The Emacs-Lisp Interface".
1240 [AT&T92] Plan 9 Programmer's manual, Murray Hill, New Jersey, 1992.
1242 [Far89] Far too many people, XTERM(1), Massachusetts Institute of Technology, 1989.
1244 [Gans93] Emden R. Gansner and John H. Reppy, ``A Multi-threaded Higher-order User Interface Toolkit'', in
1246 Software Trends, Volume 1,
1247 User Interface Software,
1249 Bass and Dewan (Eds.),
1250 John Wiley & Sons 1993,
1253 [Lucid92] Richard Stallman and Lucid, Inc.,
1255 Lucid GNU EMACS Manual,
1259 [Pike87] Rob Pike, ``The Text Editor \f(CWsam\fP'', Softw. - Pract. and Exp., Nov 1987, Vol 17 #11, pp. 813-845; reprinted in this volume.
1261 [Pike88] Rob Pike, ``Window Systems Should Be Transparent'', Comp. Sys., Summer 1988, Vol 1 #3, pp. 279-296.
1263 [Pike89] Rob Pike, ``A Concurrent Window System'', Comp. Sys., Spring 1989, Vol 2 #2, pp. 133-153.
1265 [PPTTW93] Rob Pike, Dave Presotto, Ken Thompson, Howard Trickey, and Phil Winterbottom, ``The Use of Name Spaces in Plan 9'',
1266 Op. Sys. Rev., Vol. 27, No. 2, April 1993, pp. 72-76,
1267 reprinted in this volume.
1269 [Pike91] Rob Pike, ``8½, the Plan 9 Window System'', USENIX Summer Conf. Proc., Nashville, June, 1991, pp. 257-265,
1270 reprinted in this volume.
1272 [Pike92] Rob Pike, ``A Minimalist Global User Interface'', Graphics Interface '92 Proc., Vancouver, 1992, pp. 282-293. An earlier version appeared under the same title in USENIX Summer Conf. Proc., Nashville, June, 1991, pp. 267-279.
1274 [Pike93] Rob Pike and Ken Thompson, ``Hello World or Καλημέρα κόσμε or
1275 \f(Jpこんにちは 世界\fP'', USENIX Winter Conf. Proc., San Diego, 1993, pp. 43-50,
1276 reprinted in this volume.
1278 [Pres93] Dave Presotto and Phil Winterbottom, ``The Organization of Networks in Plan 9'', Proc. Usenix Winter 1993, pp. 271-287, San Diego, CA,
1279 reprinted in this volume.
1281 [Reis91] Martin Reiser, \fIThe Oberon System,\fP Addison Wesley, New York, 1991.
1283 [Reppy93] John H. Reppy,
1284 ``CML: A higher-order concurrent language'', Proc. SIGPLAN'91 Conf. on Programming, Lang. Design and Impl., June, 1991, pp. 293-305.
1286 [Sche86] Robert W. Scheifler and Jim Gettys,
1287 ``The X Window System'',
1288 ACM Trans. on Graph., Vol 5 #2, pp. 79-109.
1290 [Stal93] Richard Stallman,
1292 Gnu Emacs Manual, 9th edition, Emacs version 19.19,
1296 [Swei86] Daniel Sweinhart, Polle Zellweger, Richard Beach, and Robert Hagmann,
1297 ``A Structural View of the Cedar Programming Environment'',
1298 ACM Trans. Prog. Lang. and Sys., Vol. 8, No. 4, pp. 419-490, Oct. 1986.
1300 [Wint94], Philip Winterbottom, ``Acid: A Debugger based on a Language'', USENIX Winter Conf. Proc., San Francisco, CA, 1993,
1301 reprinted in this volume.
1303 [Wirt89] N. Wirth and J. Gutknecht, ``The Oberon System'', Softw. - Prac. and Exp., Sep 1989, Vol 19 #9, pp 857-894.
projects / plan9front.git / blob