Xref: utzoo comp.editors:36 comp.lang.lisp:564
Path: utzoo!mnetor!uunet!husc6!mit-eddie!uw-beaver!cornell!rochester!PT.CS.CMU.EDU!IUS2.CS.CMU.EDU!ralphw
From: ralphw@IUS2.CS.CMU.EDU (Ralph Hyre)
Newsgroups: comp.editors,comp.lang.lisp
Subject: Re: lisp environments (Structure vs. text editors)
Message-ID: <499@PT.CS.CMU.EDU>
Date: 13 Dec 87 16:08:24 GMT
References: <487@PT.CS.CMU.EDU> <460@cresswell.quintus.UUCP>
Sender: netnews@PT.CS.CMU.EDU
Followup-To: comp.editors
Organization: Carnegie-Mellon University, CS/RI
Lines: 70

[I have directed followups to comp.editors, where they belong for this
branch of discussion]

In article <460@cresswell.quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes:
>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...

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.

>...For example:  a structure editor can supply different commands, different
>facilities, for editing comments and code.
Seems like there's the potential here for moby modefulness.  I can't see
why I would want different commands when I edit code compared with comments.
Perhaps some do.  More importantly I'm worried about any implementation
where these decisions are hard-coded into the source code of the particular
structure editor in use.

One of the reasons I use emacs and selected emacs-based tools is that 
they provide a consistent user-interface when programmed properly.
EMACS is completely programmable in this regard, it's just a matter of
whether you want to have a fixed view of editing or a completely
open (and programmable) one.  Depending on how the systems are designed,
the only issue is where you take your performance hit.  Under X here,
someone found that GNU emacs used ~22 system calls per keystroke.

My interest is in an pseudo-WYSIWYG editor which gives you the option
of entering/editing text without formatting attributes, then optionally 
displaying the text with them. I'm hoping that the Andrew base editor toolkit
will provide facilities for this.  This sort of decoupling between editing a
document and a representation of a document could even be used to great
advantage in many environments:

	A text editor might keep optional information on parts of speech and
	correct spellings, to help produce better documents by allowing 
	spelling and grammar checking to happen as the text is being entered.
	With current technology, the user would need to run one pass of the
	spelling checker, another of the grammar checker, then yet another of
	the spelling checker to check for grammar/spelling interactions.
	(I sometimes type 'then' when I mean 'the'.)

	A program code editor might actually be showing you variable names,
	statements, and S-expressions while it is really writing the P-code
	(or .lbin file) on the fly.

	This could result in 'instant' language interpreter facilities and 
	fast compilers.

	[I admit that this might be hairy to program in MockLisp.]

[disclaimer: I've never used a 'structure editor' except for the MacPascal
editor, it kept getting in the way.  I have used some EMACS packages (like
Scheme mode) which meet my needs without taking away functionality.]
--
					- Ralph W. Hyre, Jr.

Internet: ralphw@ius2.cs.cmu.edu    Phone:(412)268-{2847,3275} CMU-{BUGS,DARK}
Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA
-- 
					- Ralph W. Hyre, Jr.

Internet: ralphw@ius2.cs.cmu.edu    Phone:(412)268-{2847,3275} CMU-{BUGS,DARK}
Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA