Path: utzoo!attcan!uunet!zephyr.ens.tek.com!uw-beaver!milton!dali.cs.montana.edu!uakari.primate.wisc.edu!sdd.hp.com!decwrl!ucbvax!ANDREW.CMU.EDU!zs01+ From: zs01+@ANDREW.CMU.EDU (Zalman Stern) Newsgroups: comp.soft-sys.andrew Subject: Re: ez and GNUemacs. Message-ID: Date: 4 Aug 90 06:17:23 GMT References: Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 81 Nathaniel Borenstein writes: > Well, those are the arguments I would make, but I think they are > relevant because it was my impression that what you're calling ez was an > evolutionary development, not a whole new program. I believe there is > still code in ez that is recognizably code from the original edittext > and xyzzy; certainly there is a lot left over from bx. Gnumacs, on the > other hand, was a complete rewrite, as I understand it, in order to > follow the GNU philosophy of software unencumbered by any previous > copyright. \begin{flame} Your impression is wrong. I've also run into people who claim that Mach is just Accent run through a Pascal to C translator. I find such statements extremely galling in that they deny good work done by good people. Imagine how you would feel if someone said "Messages is just BAGS translated into C with some user interface enhancements picked up from ReadMail and ReadNews." (For the info-andrew readership: BAGS was a MockLISP mail/bboard reader written by Nathaniel before he came to the ITC. ReadMail and ReadNews were two programs written by Tom Peters and are to edittext as messages is to ez. Messages bears little relationship to either of these three programs.) The redraw code and editing commands for text were completely rewritten by Mike Kazar going from edittext to bx. This code was significantly cleaned up (i.e. made readable by mere mortals) by Andy Palay in the conversion to class. Later Andy add BitBlit scrolling and smooth inverted rectangle cursors. (After which point he might as well have rewritten it for all the original code you can recognize.) Tom Neuendorffer eliminated whole line redraw. Since then I have fixed a number of bugs, but not rewritten much. The entire style handling code was significantly redesigned by Mark Sherman and Maria Wadlow about the time we went from bx to ez. A lot of code had to be written to support datastream and the different template model. Text commands were rewritten completely By Mike Kazar for bx and somewhat reworked by Mike and myself for ez. (Tom N. added inset commands.) Printing stayed much the same from edittext until Jaap Akkerhuis and Tom N. redid it last year. Remaining parts of ez are things like file/buffer handling and ezapp all of which I wrote from scratch. In addition, many other things like the current event handling model, frame, keymaps and proctables (done by David Nichols) came into being about the time of ez. \end{flame} 1) Almost all the code was rewritten going from edittext to bx to ez. It doesn't matter anyway since a lot of the technology involved is well understood and doesn't change much in user perceptible ways. 2) We should be discussing user interface concepts instead of what the C code looks like. GNU emacs inherits >90% of its user interface from previous versions of emacs. Ez inherits somewhat less of its user interface from previous ITC editors. (Edittext did not have multiple buffers for example.) 3) We knew about emacs (GNU and otherwise) when we did ez. We considered it of some but not overriding importance for the following reasons: - ATKs main feature was to be extensible to editing different graphical media. Emacs only does text in a single fixed width font. - We were doing a user interface toolkit not just an editor. This placed demands of generality upon us that emacs did not have to meet. - We were designing an editor for novice users. Many people thought MacWrite was a better model than emacs. (Being CS geeks, we put as much of emacs in as we could anyway.) - Memory was supposed to be tight. Writing it in LISP was not an option. 4) Of the above items, I believe ATK is: - a good research (i.e. throwaway) system for extensible media - the best designed X11 toolkit, but too flaky and incomplete to really use - a compromise that doesn't work wonderfully well for novices or hackers. (See flaky and incomplete above.) - A failure at memory conservation. If I had known that our primary audience would be CS professionals and that our delusions of generality were doomed to fail anyway, I would have done things differently. Sincerely, Zalman Stern | Internet: zs01+@andrew.cmu.edu | Usenet: I'm soooo confused... Information Technology Center, Carnegie Mellon, Pittsburgh, PA 15213-3890 (This message was composed and mailed using BatMail under GNUemacs.)