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
rpd@F.GP.CS.CMU.EDU (Richard Draves) (12/14/87)
>From: ralphw@IUS2.CS.CMU.EDU (Ralph Hyre) >the only issue is where you take your performance hit. Under X here, >someone found that GNU emacs used ~22 system calls per keystroke. Well, since that was me, let me post the full story. I was working with GNU Emacs 18.41 and X 10.4. I have since hacked Emacs so that the basic read echo loop takes 5 system calls (select/read/sigblock/write/sigsetmask) and operations requiring more complicated redisplay (like ^V) will do about as well (the number of write depends on how often Xlib's buffer overflows). 29-Oct-87 22:59 Richard.Draves more frightening GNU Emacs stats From: Richard.Draves@F.GP.CS.CMU.EDU I traced through all the processing GNU Emacs does for a normal self-inserting character that doesn't need any special handling (eg, makes buffer modified, triggers auto-filling, etc), when running under X. Without CMU modifications, to read and echo such a character takes 27 system calls. (The system calls I count here are only those made directly by GNU Emacs.) With my (rather stupid) modifications (but somehow they fit right in), it takes 36 system calls (5 more sigsetmasks and 4 more sigblocks). The 27 system calls breaks down as 7 FIONREAD ioctls, 5 sigsetmasks, 5 sigblocks, 5 writes, 3 kills, 1 select, and 1 read. The writes are particularly frightening, because potentially the display server wakes up to process every one of them individually. This is especially costly if your Emacs is running on a remote machine. I don't know how a TCP/IP socket will actually handle the 5 writes. I also looked at scrolling with C-v. Fortunately, it doesn't do a write for each line. However, there is a large cost in sigblocks and sigsetmasks, 5 each for lines that are longer than the old line and 7 each for lines that are shorter than the old line. Considering overhead system calls, this means 250 system calls is a very conservative estimate of the average number required to scroll a 24-line page. The CMU modifications aren't significant here. To convince you I'm not making this all up, here is a list of the 27 system calls used to read and echo a character. I will start with Emacs blocked in select, waiting for input. It got there from command_loop_1, which calls read_key_sequence, which calls get_char, which calls kbd_buffer_get_char, which calls wait_reading_process_input, which calls select. Emacs has FASYNC set on the socket connecting it to the display server, so when events come in it gets a SIGIO signal. The signal handler reads and processes the X events. Whenever code in the main line wants to use any of the X code, it must protect against a SIGIO signal with sigblock/sigsetmask. 1) select (in wait_reading_process_input) [an X event comes in, unblocking the select & triggering the SIGIO handler] 2) ioctl (called by handler) 3) sigblock (called by XTread_socket) 4) ioctl (called by XPending) 5) read (called by XPending) [the X event is processed & turned into a character] 6) ioctl (called by XPending) 7) sigblock (called by xfixscreen) 8) write (xfixscreen calls (an noop) XPixfill & XFlush) 9) sigsetmask (called by xfixscreen) 10) kill (called by xfixscreen) [now a SIGIO is held] 11) sigsetmask (called by XTread_socket) 12) ioctl (called by handler) [the handler exits but is immediately called again] 13) ioctl (called by handler) [main line in wait_reading_process_input resumes & calls xfixscreen] 14) sigblock (called by xfixscreen) 15) write (called by xfixscreen) 16) sigsetmask (called by xfixscreen) 17) kill (called by xfixscreen) [SIGIO handler is called now] 18) ioctl (called by handler) [back to wait_reading_process_input, which returns back to command_loop_1, which calls direct_output_for_insert, which calls XTwrite_chars, which calls writechars] 19) sigblock (called by writechars) 20) write (CursorToggle (called by writechars) calls XPixSet/XFlush) [writechars calls XText to echo the character] 21) write (CursorToggle (called by writechars) calls XPixSet/XFlush) 22) sigsetmask (called by writechars) [writechars returns to command_loop_1, which calls read_key_sequence, which calls get_char, which calls kbd_buffer_get_char, which calls wait_reading_process_input, which calls xfixscreen] 23) sigblock (called by xfixscreen) 24) write (called by xfixscreen) 25) sigsetmask (called by xfixscreen) 26) kill (called by xfixscreen) [SIGIO handler is called now] 27) ioctl (called by handler) [now wait_reading_process_input goes to sleep in select, leaving us back where we started] Rich ----------
fritzson@bigburd.PRC.Unisys.COM (Richard Fritzson) (12/14/87)
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 > >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 Sure it can do anything. The best way for a programmable text editor to simulate a structure editor would be for it to build an internal representation (or structure) or what was really being edited and then use its text manipulating primitives to show the user the effect of his editing commands on the structure that is "really" being edited. Now you've shown that mocklisp (for example) is a language in which you can implement a structure editor. I doubt if it is the best way to do it though. >>...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. I don't know about "commands", but Common Lisp comments are nothing like Common Lisp code (much to the shame of Common Lisp). I want the characters I type in as comments treated differently than those I type in as parts of S-expressions. >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. <...>This sort of decoupling between editing a >document and a representation of a document could even be used to great >advantage in many environments: You're right. An editor which is really editing the structure underlying the visual presentation of it IS a useful thing. > 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.] But it is one of the reasons Xerox structure editor fans are fans. >[disclaimer: I've never used a 'structure editor' No offense intended, but I could tell. If you write any Lisp you should look for an opportunity to try SEdit on a D-machine. -- -Rich Fritzson ARPA: fritzson@prc.unisys.com UUCP: {sdcrdcf,psuvax1,cbmvax}!burdvax!fritzson