biep@cs.vu.nl (J. A. "Biep" Durieux) (12/15/87)
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?? In article <460@cresswell.quintus.UUCP>, pds@quintus.UUCP (Peter Schachte) writes: >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... In article <499@PT.CS.CMU.EDU> ralphw@IUS2.CS.CMU.EDU (Ralph Hyre) writes: >I disagree - a PROGRAMMABLE text editor can do anything you want. This is >because it's programmable. Whether you're happy with the performance or a >particular implementation is a separate, but important issue. Just try, in whatever programmable text editor you want, to edit the code of the editor itself, implementing new commands, and use each command in the same session immediately after its code is edited in. That's the difference between text and structure editors: whether the thing which is changing is "the real thing" or a text copy. -- Biep. (biep@cs.vu.nl via mcvax) To be the question or not to be the question, that is.
ram@WB1.CS.CMU.EDU (Rob MacLachlan) (12/16/87)
I really hate to introduce the light of reason into this debate where most
arguments have been of the form:
X is clearly better than Y (of course I've never used a Y).
...but my passion for truth and justice compels me to set the record
straight.
First, let me point out a terminological problem: most people have been
using the term "structure editor" to mean what I will call a "list structure
editor". This is an editor that represents the object being edited using
the standard list representation. There are various problems associated
with the use of the list representation, and Common Lisp exacerbates these
problems in many ways.
But... It is entirely possible to have a structure editor for Lisp that
uses a richer representation for the program that the default list
representation. Elements of Common Lisp syntax such as "#+", ";" and
package syntax can all be represented in a structured syntax-driven way. A
syntax-directed editor for Lisp could be built using this representation.
Having defined some terms, I will now claim that:
Neither a pure text editor nor a list structure editor provide an
acceptable level of support for Lisp programming.
Of course, all of the text editor proponents have been using editors that
had non-trivial knowledge about Lisp syntax and numberous syntax-directed
commands.
My main objection to a list structure editor is that the standard list
representation is a rather impovrished representation for a program. I am
in the habit of using judiciously chosen vertical whitespace and line breaks
to enhance the readability of my program. I also divide my files into pages
in order to indicate higher level strucure. All this information would be
lost by shoving the program through the reader.
A pure list structure editor also has serious difficulties with comments,
since a comment is an actual component of the evaluated form, and thus must
have a value. This was a problem in the ancient Interlisp structure editor
I once used. I certainly hope that in the state-of-the-art structure
editors being defended here it is possible to introduce comments without
fear of changing the meaning of your program, but any such facility must
involve a step away from a pure list structure editor.
Most people out there like their programming environments. They have
developed various explanations for why their environments are so winning,
but these rationalizations really miss the point. Often a minor, almost
accidental, feature of the environment is used to explain the synergistic
effect of the entire environment. This is definitely the case in the text
v.s. structure editor discussion.
There are two features of Lisp environments that are clearly beneficial:
-- Powerful editing commands that know about Lisp.
-- Interactive, incremental development.
We have been seeing various claims that these features are the sole property
of "structure editors", when in fact neither of these depend on using a list
structure representation.
For example:
>Just try, in whatever programmable text editor you want, to edit the code of
>the editor itself, implementing new commands, and use each command in the
>same session immediately after its code is edited in.
I am one of the primary implementors of Hemlock, a text editor written in
Common Lisp. I have interactively defined commands many times.
>That's the difference between text and structure editors: whether the thing
>which is changing is "the real thing" or a text copy.
This is a red herring. As any Lisp system programmer knows, redefining the
system out from under yourself is a constant problem. It is a clear
advantage to require a confirmation (such as "Compile Defun") that editing
is complete.
It is also not true that "text editors" are forced to consider your program
to be undifferentiated text. Like the EMACS-descended Lisp machine editors,
Hemlock behaves differently depending on the syntactic context. For
example, indentation and justification act differently within comments and
strings. (By EMACS, I mean ITS EMACS, not the bastard Gosmacs.)
In fact, one could make an argument that Zmacs and Hemlock really are
"structure editors", since they incrementally annotate the text
representation with non-trivial syntactic information such as "inside a
comment".
It is also not true that there is any simple relationship between:
-- The editor being written in Lisp.
-- The editor being in the same Lisp environment as the user program.
-- The editor being a list structure editor.
As any Lisp programmer knows, there are obvious advantages to the editor
being written in Lisp. Lisp is such a wonderful language for building
interactive extensible systems that the Unix emacses are built around
mini-lisp implementations.
It would be silly to write a list structure editor in any language other
than Lisp, since the only advantage of the list structure representation is
its naturalness within Lisp. But it would be quite possible to write a
structure editor for Lisp in some other language, and as much as lisp
weenies hate to admit, there would be some advantages.
It is possible to have both structure and text editors that run in the same
environment as the user program: the Interlisp and Lisp machine editors are
examples.
There are also editors written in Lisp that run in a different Lisp process
from the user program. Hemlock supports this style, and it has many
advantages, especially for systems programming. Running in a separate
process doesn't imply inferior interactivity; it just adds a barrier against
the propagation of lossage.
It would be possible to have a list structure editor written in Lisp that
ran in a different process from the user program, but I don't know of any
instances.
It would be more productive if people attempted to determine which features
of their Lisp environments were actually desirable, rather than defending
the implementation strategy and all of the incidental ramifications.
Rob MacLachlan (ram@c.cs.cmu.edu)
CMU Common Lisp -- making the world safe for symbolic computing.gudeman@arizona.edu (David Gudeman) (12/16/87)
In article <961@klipper.cs.vu.nl> biep@cs.vu.nl (J. A. "Biep" Durieux) writes: >Just try, in whatever programmable text editor you want, to edit >the code of the editor itself, implementing new commands, and use >each command in the same session immediately after its code is >edited in. >That's the difference between text and structure editors: whether >the thing which is changing is "the real thing" or a text copy. I do that all the time in GNU Emacs (a programmable text editor). What's the big deal?
jeff@aiva.ed.ac.uk (Jeff Dalton) (12/20/87)
In article <522@PT.CS.CMU.EDU> ram@WB1.CS.CMU.EDU (Rob MacLachlan) writes: <a clear and reasonable presentation of the issues> Thank you. The distinction between structure editors (in general) and list-structure editors should be kept in mind if this discussion continues. >In fact, one could make an argument that Zmacs and Hemlock really are >"structure editors", since they incrementally annotate the text >representation with non-trivial syntactic information such as "inside a >comment". I suggested that this might be done in an earlier message and so am glad to see it's actually been implemented. 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