From: utzoo!decvax!ucbvax!C70:editor-people Newsgroups: fa.editor-p Title: Article-I.D.: ucb.1179 Posted: Tue May 25 21:10:44 1982 Received: Sat May 29 03:11:30 1982 >From KLOTZ@MIT-AI Tue May 25 20:10:48 1982 Since most of the people reading this won't know who I am, I'll explain somewhat. I've worked on EMACS here for a while, involved with suggested changes for about two years. I also worked with the Logo group and participated in the design of a small editor for children to use with Logo on micro's. We chose to use the EMACS model of text in the editor, and found that it works quite well with kids. I've used editors on various machines which have some of the ``features'' described in previous messages: truncation instead of wrap on long lines, replace-mode editing, and ``anything-goes'' cursor motion. I found that I dislike them, and feel glad that there is at least one editor that does what I consider to be the right thing. I think that it would be a grievous error to change the basic organization of EMACS in order to speed it up on a not-yet-fully-designed machine. EMACS has had many years of user-testing, whereas (I suspect) the proposed optimizations for the 2080/IO-processor scheme are based on models of what programs do that don't include the sort of processing that EMACS does. Perhaps the DEC designers are aware of EMACS behavior, but don't think that it's important. Frequently, people think of an editor as ``just another program'' and don't consider it's exact behavior very important; however, many people (including me) spend most of their logged-in time in an editor, and if it does something that makes me have to stop and think about the fact that I am editing text using an editor, then it is disrupting my train of thought and impeding my work. I think that the proposed feature changes would be detrimental, but I'm not going to explain why because everyone probably knows anyway. I just think that those who are arguing for the changes might want to consider that the current behavior might be very important, and that any editor without it would not be EMACS. (Just a thought: If the people who now know TECO and maintain EMACS decided that the new editor wasn't EMACS, then who would maintain it? I guess the new editor would probably be re-implemented in another language, anyway.) While I think that a discussion of these basic issues of EMACS display and its model of text are useful in a basic discussion of editor technology, I don't think they are very important with respect to the task supposedly at hand -- converting ITS/TOPS20 EMACS to run efficiently enough on the 2080 to encourage people to use it. What I would like to see (and participate in, if I had anything to contribute) is a discussion about how to implement RMS's local-editing protocol, or something like it, in the 2080/io-processor system. Also, (of course) ideas about other, completely different schemes of allowing EMACS to run efficiently. Leigh.