Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!snooze.UUCP!layer
From: layer@snooze.UUCP (Kevin Layer)
Newsgroups: comp.lang.lisp
Subject: Re: Unix Lisp Environments (why the slow evolution)
Message-ID: <8905110103.AA04243@snooze>
Date: 11 May 89 01:03:36 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 28

In answer to jdye@ads.com (John W. Dye Jr.):

    3)  Finally, Emacs isnt that bad.  It's programmable, and with the
	right set of hacks and tags tables it begins to approximate the
	typical symbolics compile-test-debug cycle that we are all so
	familiar with.

Not true.  We have coupled GNU Emacs and Allegro CL very tighly via
TCP/IP communication channels using multiprocessing (a scheduler built
on stack groups) in Allegro CL.  Things like completion of Lisp
symbols and M-. from Emacs dynamically query the Lisp environment for
information, in real time (completion of symbols is instaneous on a
Sun3/160).

    The biggest problem we still face is debugging a multiprocessing lisp
    using emacs only (we dont like sunview--OK!).  It would be nice to have
    a facility like the lucid editor provides in good old gnu emacs.

Again, we have almost reproduced a Lisp machine environment using just
GNU Emacs.  The `almost' comes from the fact that the interpreter for
Emacs and Lisp are different (and always will be), so you must write
editor programs in Emacs Lisp and everything else in Common Lisp.  I'm
not sure what problems you are talking about here, but our debugger
allows the interactive debugging of a process in one window from
another.

	Kevin Layer
	Franz Inc.