Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!quintus!pds
From: pds@quintus.UUCP (Peter Schachte)
Newsgroups: comp.lang.lisp
Subject: Re: lisp environments
Message-ID: <460@cresswell.quintus.UUCP>
Date: 11 Dec 87 23:33:17 GMT
References: <487@PT.CS.CMU.EDU>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 68
Summary: Text editors CANNOT simulate structure editors

In article <487@PT.CS.CMU.EDU>, spe@SPICE.CS.CMU.EDU (Sean Engelson) writes:
> With regard to the text vs structure editor controversy: text editors
> can simulate structure editors easily (e.g. Emacs-like programmable
> ones), but can structure editors simulate text editors??

Text editors CANNOT simulate structure editors.  They can do a rather
feeble job of it.  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.  Or you may want to have
different commands when you're editing code than when you're editing
structure declarations.

To answer your question, structure editors can feebly simulate text
editors.  A good one can give you the feel of a text editor, in that you
type or delete pretty much anywhere in the code.  But a true structure
editor will have problems letting you delete a single parenthesis.

It might be argued that deleting a single parenthesis doesn't make
sense, because that would mean that either the before or after the
deletion, the code was asyntactic.  And why would you want asyntactic
code?  But this is not a good argument.  Sometimes it's quite natural to
look at code as text, and see that what you have is right, except you
really want THAT parenthesis over THERE.  Of course, a structure editor
could supply an operation to move a parenthesis around arbitrarily, but
sometimes it really is most natural to allow the program to be
asyntactic for a little while.

What I would like to have is a hybrid editor that maintains both the
structure of what you're editing and the text, and works really hard to
keep them in sync.

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.

Some people find the restriction of being syntactically correct all the
time too great.  Personally, I find that when I edit code with a text
editor, I almost always have to make several tries at it to get it to
parse properly.  Yes, I do have parenthesis balancing and
s-expression-at-a-time movement commands in my text editor (an emacs
lookalike), and that's how I ultimately, painfully, find the missing or
extra parenthesis.  But it's just not the same as having my code kept
always syntactically correct.  Between never having to worry about
syntax, never having to layout my code, and having commands that rely on
context, I find writing and editing code with Interlisp's SEdit goes
MUCH, MUCH faster than it does with an Emacs-alike.

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'm not complaining that people use text-based development tools.  Only
that it's being made difficult for me to use my preferred tools.  (As an
aside I'll point out that in the past, Interlisp-D made
text-editor-based development quite painful.  But it's a lot better
now.)
-- 
-Peter Schachte
pds@quintus.uucp
...!sun!quintus!pds