Path: utzoo!mnetor!uunet!mcvax!ukc!its63b!aiva!jeff
From: jeff@aiva.ed.ac.uk (Jeff Dalton)
Newsgroups: comp.lang.lisp
Subject: Re: lisp environments
Message-ID: <213@aiva.ed.ac.uk>
Date: 16 Dec 87 17:42:11 GMT
References: <487@PT.CS.CMU.EDU> <460@cresswell.quintus.UUCP>
Reply-To: jeff@uk.ac.ed.aiva (Jeff Dalton)
Organization: Dept. of AI, Univ. of Edinburgh, UK
Lines: 76

In article <460@cresswell.quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes:
>Text editors CANNOT simulate structure editors.

They cannot duplicate all features of all structure editors easily, but
they can simulate the basic feature: they can manipulate text in units
defined by language syntax rather than simply as sequences of characters.
Some people find this simulation adequate; others do not.

>Text editors fall down when context information is
>needed in order to decide what to do.  For example:  a structure editor
>can supply different commands, different facilities, for editing
>comments and code.  For languages with C/Pascal style comments (that can
>span multiple lines), this cannot be effectively done with a text
>editor.  Not, at least, without being willing to search all the way back
>to the beginning of the file to see if we're in a comment whenever we
>want to do something that's context sensitive.

But they *are* willing to search all the way back to the beginning of
the file.  Emacs potentially does this when computing indentation levels.
Of course, most times it needs to search back only a few lines.

Moreover, more efficient methods may be possible.  The editor may be able
to keep track of the contexts that apply at various points on the screen
and update this information as changes are made.  The screen is relatively
small when a large file is involved, and editors already do interesting
things in order to update the screen efficiently when the file changes.
(Of course, not the same interesting things, but it shows the degree of
effort they're willing to make.)

Whether this is an aspect of structure editors that text editors ought
to emulate is another matter.

>For many people, the choice between a structure editor and a text editor
>is between laying out their code themselves, and having the system do it
>for them.  Some take great care in laying out their code, aligning
>related bits in adjacent lines.  The sort of thing that's very heuristic
>and not very algorithmic.  The sort of thing that no automatic layout
>program could do.  For others, the burden is not worth the trouble, and
>they would rather settle for the best the system can do.

It is not necessarily a great burden.  Emacs does most of the indentation
for me.  In almost all cases, I provide only the line breaks.  To me this
makes a great difference for very little effort.  Many fully automatic
systems produce results that I find nearly unreadable.

>I find writing and editing code with Interlisp's SEdit goes
>MUCH, MUCH faster than it does with an Emacs-alike.

From what I've seen of SEdit, it is indeed quite nice.  Part of the
reason for this is that it is more like Emacs than DEdit was.

The truth is that it's largely a matter of taste -- I do not think either
method is inherently superior.  Unfortunately, people made the same claims
for the superiority of structure editors when only DEdit existed.  From
this, and from statements like "Emacs is worse than FORTRAN", it seems that
the advocates of structure editing are unwilling to accept that any
opposing views can be valid.

>But that's only my opinion.  What the crux of this discussion has been
>about is how CommonLisp seems to have made an incore, structure-editor
>based development system very difficult, if not in general impossible.

I don't see why.  You have to provide things like LOAD as well, however.

LOAD just lets you do from files what you can from the keyboard.  (Even
the Xerox systems let you omit the structure editor some of the time.)
This is convenient because files are portable.  Text is the one format
that everyone can use most easily.

Character macros (which may discard information) may be a greater problem,
but it can't be that they make an in-core, etc. system impossible for
Interlisp has them too.

Jeff Dalton,                      JANET: J.Dalton@uk.ac.ed             
AI Applications Institute,        ARPA:  J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University.             UUCP:  ...!ukc!ed.ac.uk!J.Dalton