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