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