jeff%aids-unix@sri-unix.UUCP (06/21/83)
From: Jeff Dean <jeff@aids-unix> I am interested in getting an editor that can be adapted as a front end for several different applications. As a front end, there are two major capabilities that I think I need. One is the ability to write a program (in the editor's langauge) to massage a part of the text being edited; the other is the ability to grab a section of the text and send it to another process. I know that many versions of Emacs claim to have this power, but I'd like to find something that is relatively portable. Does know of editors (or editor building systems) that satisfy these criteria? Thanks... Jeff Dean
MCB%mit-mc@sri-unix.UUCP (06/23/83)
From: Michael A. Bloom <MCB@mit-mc>
Probably your best choice is one of the lisp-based emacs's
ported to run under franz lisp (which is written in C, and is
close enough to maclisp to be able to run a macsyma)
Goslin's (CMU) emacs is NOT a lisp based emacs, although it
has an extension language with a syntax similar to that of a lisp.
It most notably lacks the list manipulation primitives that make
lisp lisp.
The lisp based emacs's I am aware of are:
Honeywell Emacs (Maclisp)
ZMACS ( Zeta lisp )
NIL Emacs (NIL (for VMS, and remotely maybe for UNIX))
NIL is currently written in BLISS and MACRO-VAX, (and NIL)
so is not portable.
There is also the Yale screen editor that comes as part of their
distribution of 'T', another lisp dialect.
It might be reasonable to merge one of the Emacs lookalikes that are
written in C with Franz lisp, so as to define a new type of data object,
the "buffer" with subr's that operate on it. Perhaps the same
could be done for the redisplay strategy, but people like lisp based
redisplays because each person could (in theory) have his own personal
redisplay handler.
Possible candidates for this are:
gosling's emacs, whose redisplay is considered fairly fancy. You
could rip out all of the mlisp stuff.
Bell Labs Emacs, whose status is indeterminate at the moment.
It has its own macro language made up of emacs commands with
some flow control commands added. I'm told that macros
written for it resemble TECO macros to those not versed in TECO.
CCA Emacs, which I've seen only once and liked.
and even MINCE, which does not have a display algorythm
approaching the others, but is cheap (225$ for partial source)
A good general reference is "Theory and practice of Text editors",
MIT/LCS/TM-165, free from LCS Publications (as of a year ago, anyway).CPR%mit-xx@sri-unix.UUCP (06/25/83)
From: Chris Ryland <CPR@mit-xx> Let me point out that T, the Yale Scheme derivative, has been ported to the Apollo, VAX/Unix, VAX/VMS, and, soon, the 370 family, from what I hear. It appears to be the most efficient and portable Lisp to appear on the market. John O'Donnell at Yale (Odonnell@YALE) is the T project leader. -------
BarryMargolin%mit-multics@sri-unix.UUCP (06/25/83)
NIL has flavors, it doesn't have the fancy window system
that the Lisp Machine has.
barmarJQJ@SU-SCORE.ARPA (07/01/83)
From: J.Q. Johnson <JQJ@SU-SCORE.ARPA> Michael Bloom's suggestion that those looking for a portable emacs look to to lisp-based emacs systems neglects somewhat the problem of incompatible lisps. If portability is your goal, what good does it do to have a lisp-based Emacs which depends on the idiosyncratic features of a particular lisp implementation? Bloom mentions several lisp-based editors, among them Honeywell Emacs, ZMACS, the T editor, and the NIL editor. It should be noted that Honeywell Emacs and ZMACS are heavily dependent on their particular operating system environments, especially for window management (the Honeywell Emacs is particularly ill suited for ports to other systems since, as the first lisp Emacs, it is not nearly as cleanly implemented as the others). The NIL editor requires a lisp that includes an efficient flavors implementation. None of these, I bet, would run under a lisp such as Franz without substantial development effort. I am not familiar with the T editor, but note that T is lexically scoped, and hence that a large program written in T is also likely to have portability problems to a more traditional lisp such as Franz. And once you have an editor that runs under Franz Lisp, what good does that do you for portability? Franz Lisp, with its large C kernel and VAX-oriented code generation, would be rather hard to port to other systems. So far as I know, it has not been ported to any non-VAX system (although Wollongong group claim to be working on a port to Perkin Elmer Unix). Granted, Franz is a small lisp, and it is easier to move Franz programs to Maclisp or Common Lisp than vice versa, but the effort of moving a large program such as an editor from one lisp to another is guaranteed to be non-trivial. Porting Franz to a different architecture would almost certainly be more work than porting Gosling Emacs, since to port Gosling Emacs all you really need is a decent C compiler, while to port Franz you need a C compiler PLUS you need to rewrite the Liszt (Franz compiler) code generator. Now conceivably Franz is not the right target lisp for your editor implementation language. If you really want portability, perhaps you should write an editor in PSL (portable standard lisp). That in fact is what Martin Griss and the folks at Utah did; NMODE (or whatever it is currently called) is an Emacs-like editor written in a lisp dialect that was explicitly designed to be portable, and for which implementations exist for DEC-20, VAX, M68000, and several other computers. PSL is not a very powerful lisp either, and it is not clear it will catch on widely. An alternative is Hemlock, the CMU Common Lisp editor. Many people (I'm not one of them, I'm afraid) believe that Common Lisp will become THE standard lisp in the late '80s, and hence that an editor written in pure Common Lisp stands a good chance of being widely portable. We'll see.... Alternatively, why not just port Gosling or CCA Emacs? Each of these is written pretty much entirely in C, and so could be ported to any large-address-space system that had a C compiler (a Unix operating system would help, but is not essential). In fact, Gosling Emacs has been successfully ported to several different M68000 systems (Unisoft Unix, SMI Unix (aka 4.1C BSD for 68000), and various standalone SUN terminal configurations. I'd not be at all surprised to hear that someone had ported it to the Amdahl (IBM 370 lookalike) running Unix! -------