The precursor to the sam editor on AT&T Bell Labs' Plan 9 OS
Author: Rob Pike Paper: http://doc.cat-v.org/plan_9/4th_edition/papers/sam/ Manual Page: http://man.cat-v.org/unix_8th/9/jim Family: BellLabsFamily Platform: Research Unix License: Proprietary
"History
The immediate ancestor of sam was the original text editor for the Blit, called jim. Sam inherited jim’s two-process structure and mouse language almost unchanged, but jim suffered from several drawbacks that were addressed in the design of sam. The most important of these was the lack of a command language. Although jim was easy to use for simple editing, it provided no direct help with large or repetitive editing tasks. Instead, it provided a command to pass selected text through a shell pipeline, but this was no more satisfactory than could be expected of a stopgap measure.
Jim was written primarily as a vehicle for experimenting with a mouse-based interface to text, and the experiment was successful. Jim had some spin-offs: mux, the second window system for the Blit, is essentially a multiplexed version of the terminal part of jim; and the debugger pi’s user interface20 was closely modeled on jim’s. But after a couple of years, jim had become difficult to maintain and limiting to use, and its replacement was overdue.
I began the design of sam by asking jim customers what they wanted. This was probably a mistake; the answers were essentially a list of features to be found in other editors, which did not provide any of the guiding principles I was seeking. For instance, one common request was for a ‘‘global substitute,’’ but no one suggested how to provide it within a cut-and-paste editor. I was looking for a scheme that would support such specialized features comfortably in the context of some general command language. Ideas were not forthcoming, though, particularly given my insistence on removing all limits on file sizes, line lengths and so on. Even worse, I recognized that, since the mouse could easily indicate a region of the screen that was not an integral number of lines, the command language would best forget about newlines altogether, and that meant the command language had to treat the file as a single string, not an array of lines.
Eventually, I decided that thinking was not getting me very far and it was time to try building. I knew that the terminal part could be built easily — that part of jim behaved acceptably well — and that most of the hard work was going to be in the host part: the file interface, command interpreter and so on. Moreover, I had some ideas about how the architecture of jim could be improved without destroying its basic structure, which I liked in principle but which hadn’t worked out as well as I had hoped. So I began by designing the file data structure, starting with the way jim worked — comparable to a single structure merging Disc and Buffer, which I split to make the cache more general — and thinking about how global substitute could be implemented. The answer was clearly that it had to be done in two passes, and the transcript-oriented implementation fell out naturally.
Sam was written bottom-up, starting from the data structures and algorithms for manipulating text, through the command language and up to the code for maintaining the display. In retrospect, it turned out well, but this implementation method is not recommended in general. There were several times when I had a large body of interesting code assembled and no clue how to proceed with it. The command language, in particular, took almost a year to figure out, but can be implemented (given what was there at the beginning of that year) in a day or two. Similarly, inventing the Rasp data structure delayed the connection of the host and terminal pieces by another few months. Sam took about two years to write, although only about four months were spent actually working on it.
Part of the design process was unusual: the subset of the protocol that maintains the Rasp was simulated, debugged and verified by an automatic protocol analyzer,21 and was bug-free from the start. The rest of the protocol, concerned mostly with keeping menus up to date, was unfortunately too unwieldy for such analysis, and was debugged by more traditional methods, primarily by logging in a file all messages in and out of the host."
-Rob Pike