From: utzoo!decvax!harpo!npois!ucbvax!C70:editor-people Newsgroups: fa.editor-p Title: Re: Improved support for Emacs in TOPS-20. Article-I.D.: ucb.1310 Posted: Thu Jun 10 00:39:59 1982 Received: Fri Jun 11 00:56:27 1982 Reply-To: ople >From Goldberg@RUTGERS Thu Jun 10 00:35:54 1982 Date: 24-May-82 12:51AM-EDT (Mon) From: Steve WoodSubject: Re: Improved support for Emacs in TOPS-20. ... The design of a display editor is at least as important as the design of an operating system or programming language, yet the amount of published research about display editing pales in comparison to the latter two subjects. Most of what has been written consists of general surveys of existing software. Very little has been written about what the issues are in the design and implementation of a display editor. ... I fully agree with this statement, and I would extend it to editors in general, not just display editors. In fact, the following statement appears in my Dec. 1981 Ph.D. thesis on distributed editing architectures (which has not yet been sent by Rutgers to University Microfilms, grrrr): Text editors are of greater importance than generally recognized. They are arguably the most important class of programs in existence, because of their central role in any application, and because of the amount of time people spend using them. Computer Scientists have studied the design of operating systems and programming languages in great detail, but have generally regarded text editors merely as utility programs. In reviewing the literature on the subject, one finds that very little has been written beyond broad surveys of existing software, and almost no analysis has been done of the design decisions faced by the implementor of a text editing system. I have nothing to add to the discussion of editor user interfaces, and in fact quite pointedly avoided that issue in my thesis, beyond asserting that a good architecture should allow any reasonable user interface. Building some restricted interface into TEXTI violates this principle, though I suspect that a few of the more common editing situations (such as adding text to the end of the file or line) could be optimized in a given editor using some suitably designed jsys. Indeed most timesharing editors go to some pains to optimize normal insertion of characters at the end of a line as a special case (including, I believe, TWENEX EMACS). I see two consistent themes in the correspondence here: 1) dissatisfaction with the editing response on a timeshared host, and 2) the desire to have one's preferred user interface and file model. One contributor suggests that we all buy powerful single user systems and use timeshared hosts as file servers, etc. That is fine if you can afford it. Perhaps the cost of powerful single user systems will fall enough in 5 to 10 years so that this may be an option to more than an elite few. In the mean time, given the economic reality faced by most of us that says we must use a timeshared host as both the file server and file processor for compilation, text processing, etc., I suggest that an editor distributed between the host and a dynamically programmed terminal/microprocessor does a good job of addressing these two themes. In terms of the alternatives raised by the correspondents of this mailing list, what I propose (as *one* alternative, not the *only* solution, mind you) is to handle most of the local cursor movements, insertions/deletions, local searches, etc. in the local terminal+processor itself. Simulating one possible scheme for doing this, I found that the average editing session at Rutgers would require on the order of only a dozen user-observable host wakeups (the rest would occur in the background, and there would be many fewer total host wakeups than user keystrokes). Note well that the local terminal+processor interface would have to be written to communicate with a specific program on the host, assuming the same file model as the host editor server with which it communicates; an IBM block mode style "general editing terminal" is totally inadequate unless one does not care what the user interface looks like. A further benefit of this approach is that the effective rate of communication between host and screen can be made much higher than the actual connection bandwidth, through judicious saving of previously displayed text and predictive background fetching of the "next" screenful. In fact, much of the time the window motion would not require host communication. The performance claims I make here are backed up by hard evidence in my thesis, from analysis of 15,000 actual editing sessions using a variety of editors, and through simulations of proposed schemes using the file-reference data obtained during these sessions. Let me apologize again for the bureaucratic snail's pace at which Rutgers University's thesis handling office crawls. I asked the University to send out some copies to some of you (did anyone get one yet?) and hope to have it made available though University Microfilms for the rest of you. Unfortunately, the heart of the work is the editing session analysis, which I have summarized in about 50 plotted graphs and figures, so electronic distribution is not feasible. Bob -------