spe@SPICE.CS.CMU.EDU (Sean Engelson) (12/11/87)
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?? I don't think so. Thus, text editors provide a more inclusive model of editing (i.e. model of computation) than structure editors. N'est ce pas? -Sean-
pds@quintus.UUCP (Peter Schachte) (12/12/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?? 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
ralphw@IUS2.CS.CMU.EDU (Ralph Hyre) (12/14/87)
[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
pds@quintus.UUCP (Peter Schachte) (12/15/87)
<< I tried to post this to comp.editors, but my news system didn't want to >> In article <499@PT.CS.CMU.EDU>, ralphw@IUS2.CS.CMU.EDU (Ralph Hyre) writes: > 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... > > 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. When performance gets bad enough, it BECOMES the central issue. If Emacs spends several seconds determining context for EACH KEYSTROKE, it becomes unusable. > > >...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. Don't you switch Emacs to text mode to edit block comments? Line wrap is so useful there. Better yet, why not have the paragraphs auto-filled and auto justified while you type, like a word processor? Make your comments look nice. Use boldface, italics, large headings, etc. Why not? Just because your tools won't let you? > ... it's just a matter of > whether you want to have a fixed view of editing or a completely > open (and programmable) one. No, it's a matter of what information you want available to your programs. There's nothing to say that a structure editor can't be programmable. A programmable text editor has access to the text of a program or document, and must parse it in order to determine context. A structure editor has access to the structure of program or document, and must unparse (print) it in order to keep the screen up-to-date. Printing is usually easier than parsing. > > [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.] Sometime, try SEdit, the new Interlisp structure editor. It still has some weaknesses, but you might be surprised at how much it can look like a text editor, and how much advantage it takes of having the structure around. You might be pleasantly surprised. -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds
barmar@think.COM (Barry Margolin) (12/16/87)
I'm posting this for a friend who used to work for Symbolics; his current employer's policy requires him to post this anonymously: ----------------- As a maintainer of the Symbolics editor subsystem, I did exactly what the gentleman from the netherlands posits. I edited the source of the editor in the editor with immediate modification feedback. In the Symbolics system, all of the language tools used by the compilers are available to the rest of the system via *dynamic linking*. The editor maintains a partial parse of the program in an auxiliary data structure. It uses event counts to update the parse as the user changes the code. The partial parse handles errors, so that you can have intermediate states in which the program is invalid, unlike a structure editor. However, the partial parse permits features like a command that gives the argument requirements for a function indicated by the mouse, highlighting of errors, a mouse click which fetches the source of an indicated function or variable, a mouse click to place a breakpoint in a program, and a set of commands to step through compiler errors finding the precise point of error. (the compiler annotates the actual editor representation if you compile a file from the editor.) These are only the very tip of the iceberg. Its always depressing to see a bunch of people yammering back and forth with a religious dispute instead of finding the compromise position right in front of their noses. ----------------- Now to my own comments on the subject. First of all, I have also edited portions of the Symbolics editor in the editor. Another posting mentioned that only structure editors can automatically provide different commands depending on whether you are editing code or comments, but the Symbolics editor does a great job of this. They have an "Electric Font Lock" and "Electric Shift Lock" modes, which automatically change the typein font and case depending on whether you are typing in code, string literals, or comments, and I don't know what I'd do without "Auto Fill Lisp Comments" and "Fill Long Comment" when typing block comments. They don't actually bother changing key bindings when you are in a comment, but there's no reason they couldn't. --- Barry Margolin Thinking Machines Corp. barmar@think.com seismo!think!barmar
pds@quintus.UUCP (Peter Schachte) (12/16/87)
In article <13731@think.UUCP>, barmar@think.COM (Barry Margolin) writes: > I'm posting this for a friend who used to work for Symbolics > ----------------- > ...The editor > maintains a partial parse of the program in an auxiliary data structure. > It uses event counts to update the parse as the user changes the code. So the Symbolics editor is a text AND structure editor! This approach seems like it has the best of both worlds. But how partial is partial? And how long does it take to start up an edit on a fairly large file? Will it let you know you have a syntax error before you get far afield? Or do you have to explicitly ASK the system? > Its always depressing > to see a bunch of people yammering back and forth with a religious dispute > instead of finding the compromise position right in front of their > noses. I did suggest a compromise in an earlier posting. -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds
barmar@think.COM (Barry Margolin) (12/16/87)
In article <460@cresswell.quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes: > 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. How does Common Lisp PREVENT you from using an incore, structure-editor-based development system? What facilities does such a system require besides EVAL, SYMBOL-FUNCTION, and COMPILE? And even if these weren't defined in Common Lisp, who says that the development system has to be written in portable Lisp; since there's no standard Common Lisp interface to display terminals, it couldn't be portable if it were a display editor, and I don't think you were talking about a line-oriented structure editor. For example, the Scheme standard doesn't include EVAL or COMPILE, yet there are incore Scheme development systems (I think most Scheme implementations include EVAL, it's just not in the standard because it violates the philosophy of the language). --- Barry Margolin Thinking Machines Corp. barmar@think.com seismo!think!barmar
jeff@aiva.ed.ac.uk (Jeff Dalton) (12/17/87)
In article <460@cresswell.quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes: >Text editors CANNOT simulate structure editors. They cannot duplicate all features of all structure editors easily, but they can simulate the basic feature: they can manipulate text in units defined by language syntax rather than simply as sequences of characters. Some people find this simulation adequate; others do not. >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. But they *are* willing to search all the way back to the beginning of the file. Emacs potentially does this when computing indentation levels. Of course, most times it needs to search back only a few lines. Moreover, more efficient methods may be possible. The editor may be able to keep track of the contexts that apply at various points on the screen and update this information as changes are made. The screen is relatively small when a large file is involved, and editors already do interesting things in order to update the screen efficiently when the file changes. (Of course, not the same interesting things, but it shows the degree of effort they're willing to make.) Whether this is an aspect of structure editors that text editors ought to emulate is another matter. >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. It is not necessarily a great burden. Emacs does most of the indentation for me. In almost all cases, I provide only the line breaks. To me this makes a great difference for very little effort. Many fully automatic systems produce results that I find nearly unreadable. >I find writing and editing code with Interlisp's SEdit goes >MUCH, MUCH faster than it does with an Emacs-alike. From what I've seen of SEdit, it is indeed quite nice. Part of the reason for this is that it is more like Emacs than DEdit was. The truth is that it's largely a matter of taste -- I do not think either method is inherently superior. Unfortunately, people made the same claims for the superiority of structure editors when only DEdit existed. From this, and from statements like "Emacs is worse than FORTRAN", it seems that the advocates of structure editing are unwilling to accept that any opposing views can be valid. >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 don't see why. You have to provide things like LOAD as well, however. LOAD just lets you do from files what you can from the keyboard. (Even the Xerox systems let you omit the structure editor some of the time.) This is convenient because files are portable. Text is the one format that everyone can use most easily. Character macros (which may discard information) may be a greater problem, but it can't be that they make an in-core, etc. system impossible for Interlisp has them too. 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
darrelj@sdcrdcf.UUCP (Darrel VanBuer) (12/17/87)
In article <13786@think.UUCP> barmar@sauron.think.com.UUCP (Barry Margolin) writes: >In article <460@cresswell.quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes: >> 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. >How does Common Lisp PREVENT you from using an incore, >structure-editor-based development system? What facilities does such >Barry Margolin >barmar@think.com >seismo!think!barmar No, CL doesn't PREVENT doing it, but it really makes it hard to import "standard" CL source files into such an environment without loss of information, mainly because reader treatment of comments, #+ and #- is hard to preserve for editing and subsequent recreation on output. They can't always be left inline (OK for source code, maybe, by embedding them in some form recognized by the interpreter and compiler, but what do you do with (DEFVAR foo ; this value depends on bar #+fum '(a b) #-foobar ;here is a tricky case 'foobar-absent) The value of foo had better be the right value, so all the comments and #+/#- has to be saved elsewhere by LOAD so that editors and file creators can find and reconstruct them. Interlisp handles much of what #+ #- do with SELECTQ (like CASE) and a note that the compiler is guaranteed to optimize away a constant selector (e.g. (SELECTQ 5 (5 'A)(6 'B) 'C) compiles as 'A ), but this is only in code; in data one would have to use backquote and ,(SELECTQ ...) etc. Still another problem is data representation - e.g. #+hugefloats 3.14159265368979323846 #+tinyfloats 3.14 #+mediumfloat 3.141593 #+incrediblyhugefloats ... #+incrediblybigarrays #A(jillions of elements ...) Its easy enough to write a reader which knows enough syntax to read any legal CL form and throw it away, but if you only have 32-bit floats, how do you represent a hugefloat for later reconstruction? There's nothing insurmountable in all this, but it certainly complicates the world by requiring some kind of shadow database and representations for objects without supported operators! -- Darrel J. Van Buer, PhD; unisys; 2400 Colorado Ave; Santa Monica, CA 90406 (213)829-7511 x5449 KI6VY darrel@CAM.UNISYS.COM or ...{allegra,burdvax,cbosgd,hplabs,ihnp4}!sdcrdcf!darrelj
pds@quintus.UUCP (Peter Schachte) (12/17/87)
In article <13786@think.UUCP>, barmar@think.COM (Barry Margolin) writes: > In article <460@cresswell.quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes: > > 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. > How does Common Lisp PREVENT you from using an incore, > structure-editor-based development system? What facilities does such > a system require besides EVAL, SYMBOL-FUNCTION, and COMPILE? You misunderstand. I'm not complaining that CommonLisp is not powerful enough for me to write an incore development system in. It's plenty powerful. I'm complaining that it's hard to write an incore development system FOR CommonLisp, in any language. I was concerned about handling features like user-defined read macros and #+, +-, etc. But I think I see how to handle them now. My remaining problem is with packages. Let me give an example. Suppose I have a package ADVENTURE which has the functions and variables to support an adventure game. This package has an external variable CHARGE (excuse me, I mean a variable whose name is the external SYMBOL CHARGE), indicating how many more turns my flashlight will last. Whatever. I'm developing this module, so I have the package USER USE ADVENTURE. Or at least USER IMPORTs ADVENTURE:CHARGE. I'm also developing a banking program. I don't know how I want to package it yet, so I'm just developing it in USER. I have a function called CHARGE which debits an account. It all works, and I want to package it now. So I decide to create the package BANKING and put everything in it. I carefully move all the symbols I've defined in USER into BANKING. But the catch is that I've also moved CHARGE from ADVENTURE into BANKING. And if I now write out ADVENTURE, and later read it in without having BANKING loaded, the file won't even READ, much less run. Here's an even more basic problem. Package FOO USEs package BAR. SYM is a symbol in BAR. Suppose I write out a file containing SYM with *PACKAGE* set to FOO. Since SYM is "visable" in FOO, it is written out without a package qualification. Unfortunately, when it is read back in, it will be put into FOO. This problem has bitten me several times. Actually, this problem is not exclusive to incore development systems. Any CL program that writes out and reads in data can have this problem. -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds
barmar@think.COM (Barry Margolin) (12/18/87)
In article <471@cresswell.quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes: >In article <13731@think.UUCP>, barmar@think.COM (Barry Margolin) writes: >> ...The editor >> maintains a partial parse of the program in an auxiliary data structure. >> It uses event counts to update the parse as the user changes the code. > >So the Symbolics editor is a text AND structure editor! This approach >seems like it has the best of both worlds. But how partial is partial? Well, in the case of Lisp it is pretty simple, because Lisp has very simple syntax. Each line of the buffer is tagged with the lexical state at the beginning of the line; this specifies how deeply nested it is, whether it is in the middle of a string, and the function definition (or other top-level form) the line is part of. There are also some heuristics that speed things up, especially useful when the file isn't totally syntactically correct; for example, the parse state is reset whenever a line that begins with an open parenthesis is seen, so that leaving off a close paren will not screw up the parsing of the rest of the file. In the case of other languages such as Pascal, C, and Ada, a real parse tree is maintained, but I don't know much about its implementation. >And how long does it take to start up an edit on a fairly large file? The extra time it takes to parse the buffer is noticeable, but not intolerable, since it is interleaved with reading the file in from the file server. >Will it let you know you have a syntax error before you get far afield? >Or do you have to explicitly ASK the system? It generally only does syntax checking when you perform an operation on a syntactic unit. For example, when you ask to compile the current Lisp function it checks that the parentheses are balanced within that definition. There is a command that searches the buffer looking for unbalanced parentheses. The only automatic syntax check I'm aware of is done when a Lisp source file is being written out; it checks parentheses as it goes, and if it notices that they aren't balanced it asks whether you want to continue writing. --- Barry Margolin Thinking Machines Corp. barmar@think.com seismo!think!barmar
shebs%defun.utah.edu.uucp@utah-cs.UUCP (Stanley T. Shebs) (01/21/88)
In article <5036@sdcrdcf.UUCP> darrelj@sdcrdcf.UUCP (Darrel VanBuer) writes: >No, CL doesn't PREVENT doing it, but it really makes it hard to import >"standard" CL source files into such an environment without loss of >information, mainly because reader treatment of comments, #+ and #- is hard >to preserve for editing and subsequent recreation on output. Comments are pretty easy to structureify, takes about two lines of code for the redefinition of ;. #+/#- slightly harder, because although you can always represent even bizarre objects by retaining the input form as a string (which is always possible, eh?), you would still have to write your own version of a suppressed reader that would return the uninterpreted goop. CL falls down by not requiring the reader to return the string, but it doesn't seem like it would be very hard for implementations to provide... stan shebs shebs@cs.utah.edu
john@linus.UUCP (John D. Burger) (05/16/89)
What about logical pathnames? We make heavy use of them to maintain code in several different version of Symbolics. They can be used to do all sorts of cute things. Does any Unix-based Lisp environment have anything comparable? -- John Burger john@mitre.org "You ever think about .signature files? I mean, do we really need them?" - alt.andy.rooney