Date: 3 October 1980 20:31-EDT From: Mike McMahon Sender: MMcM at CADR1 at MIT-AI To: MOON at MIT-AI cc: BUG-NWS at MIT-AI Date: 30 SEP 1980 0158-EDT From: Moon at MIT-AI (David A. Moon) %DRAW-RECTANGLE-CLIPPED uses negative x and y bitposes to mean something magic with wrap-around. The (STREAM-MIXIN :DRAW-RECTANGLE) method simply calls %DRAW-RECTANGLE-CLIPPED with arguments translated to inside coordinates. This means it will do completely the wrong thing for rectangles that stick out to the left or the top and need to be clipped. I imagine that method should call draw-rectangle-inside-clipped without doing any translation itself.  Date: 3 October 1980 08:51-EDT From: Howard I. Cannon Subject: Incompatible change! To: Moon at MIT-AI cc: BUG-NWS at MIT-AI This :STATUS incompatible chage probably breaks things. I'm sur that there are things that do "with sheet deexpoed" or similar using status, and for them it must work the old way. Did you check through these things? I think that what :STATUS used to do was the "right" thing, even though you might consider it less understandable. You might consider the concept of "exposed with respect to superior" hard to understand too. But that's the way it is....  Date: 3 OCT 1980 0106-EDT From: dlw at MIT-AI (Daniel L. Weinreb) Subject: Some NWS, some ZMAIL comments. To: (BUG NWS) at MIT-AI I found that if I start playing around with the initial configuration of windows on the screen, and reshape the Lisp Listener in such a way that I leave some uncovered space, I end up seeing the initial ZMAIL window. This is really non-conceptual. Should these things really be active when the system comes up? Couldn't they be all painted into their saved bit arrays, ready to appear in a single BITBLT, as soon as someone asks for them? Having that ZMAIL window sitting there ready to go has other problems. If I want to send mail, I type System M, and then have to sit there while it reads in my RMAIL file, even though I don't want to read mail. Furthermore, if I happen to use TERMINAL - S to scan through the windows, and I hit upon the ZMAIL window, it starts reading in the RMAIL file, consuming gobs of the machine. What a way to hassle me! I think it should not start reading unless you tell it to. I also think there should be a stand-alone mail sender window, so that I can create one with Create in the system menu and so on.  Date: 3 OCT 1980 0027-EDT From: Moon at MIT-AI (David A. Moon) Subject: Incompatible change! To: (BUG NWS) at MIT-AI I changed the :STATUS message so that it will return :EXPOSED only if the window is actually visible on the screen, i.e. it and all its superiors are exposed. Formerly it returned :EXPOSED if the window was exposed with respect to just its superior, which I believe to be less useful and less understandable.  Date: 2 OCT 1980 1551-EDT From: ACW at MIT-AI (Allan C. Wechsler) Subject: "Chord". To: (BUG NWS) at MIT-AI The proper word (according to CRC math tables 18th ed.) is "sector". ---Wechsler  Date: 2 OCT 1980 0448-EDT From: Moon at MIT-AI (David A. Moon) To: (BUG NWS) at MIT-AI I changed PROCESS-MIXIN not to give the process a run-reason until the first time the window is exposed or selected. This should substantially decrease the number of page faults during cold-booting. However, if such a window is used and then the world is disk-saved, the feature will be obviated. We should implement some scheme by which there is a BEFORE-COLD initialization which finds all such processes and takes away their run reasons.  Date: 1 October 1980 14:47-EDT From: Gerald R. Barber To: DLW at MIT-AI cc: BUG-NWS at MIT-AI, HIC at MIT-MC Date: 1 October 1980 14:19-EDT From: Daniel L. Weinreb Sender: dlw at CADR8 at MIT-AI To: HIC at MIT-MC cc: BUG-NWS Date: 1 October 1980 12:12-EDT From: Howard I. Cannon To: DLW at MIT-AI cc: BUG-NWS at MIT-AI It's impotant to be able to Abort conveniently. I would disagree with making it shifted in any way. I don't believe that I have ever typed it in a situation where my fingers slipped, and not my brain. .... I agree tha it would be nice to have someting more reasonable than Control-mumble to quit (abort)...isn't there another key that would make sense (we have about 20 of them, don't we?). Yes, but only the Abort key says Abort on it. The others say things like Resume and Status and Help. If we don't use Abort, we should stick to something totally unmnemonic like Control-], so as not to confuse people. But using Abort would be much better in my opinion. From the point of understandability maybe what abort does now should be [SYSTEM] [ABORT] and simple [ABORT] should be left for programs to interpret as they see fit.  Date: 1 October 1980 14:19-EDT From: Daniel L. Weinreb Sender: dlw at CADR8 at MIT-AI To: HIC at MIT-MC cc: BUG-NWS at MIT-AI Date: 1 October 1980 12:12-EDT From: Howard I. Cannon To: DLW at MIT-AI cc: BUG-NWS at MIT-AI It's impotant to be able to Abort conveniently. I would disagree with making it shifted in any way. I don't believe that I have ever typed it in a situation where my fingers slipped, and not my brain. I completely retract the point about making it hard to type; I wasn't thinking. Yeah, you are unlikely to hit it by accident. However, I do not agree that typing Control-Abort is so difficult that you would not be able to stand using it in the cases where you want an asynchronous abort to happen. It's pretty easy to type. I agree tha it would be nice to have someting more reasonable than Control-mumble to quit (abort)...isn't there another key that would make sense (we have about 20 of them, don't we?). Yes, but only the Abort key says Abort on it. The others say things like Resume and Status and Help. If we don't use Abort, we should stick to something totally unmnemonic like Control-], so as not to confuse people. But using Abort would be much better in my opinion.  Date: 1 October 1980 12:12-EDT From: Howard I. Cannon To: DLW at MIT-AI cc: BUG-NWS at MIT-AI It's impotant to be able to Abort conveniently. I would disagree with making it shifted in any way. I don't believe that I have ever typed it in a situation where my fingers slipped, and not my brain. I agree tha it would be nice to have someting more reasonable than Control-mumble to quit (abort)...isn't there another key that would make sense (we have about 20 of them, don't we?).  Date: 1 October 1980 03:48-EDT From: Daniel L. Weinreb Sender: DLW at CADR2 at MIT-AI To: BUG-NWS at MIT-AI In the version of NWS on system 44.3, with microcode 692, on LISP Machine Two: I would like to make ABORT be a normal character, and move the present function to CONTROL/ABORT. This would let us use the ABORT key as a command. A particular place I would badly like to see it is in this very mail sending to which I am typing. "End mails, Control-] quits" is not nearly so nice as "End mails, Abort aborts". Besides, the present thing is far too hot stuff to be that easy to type.  MOON@MIT-MC 09/30/80 22:34:13 Re: Your message about Packards and Stutzes To: TAFT at MIT-MC CC: (BUG NWS) at MIT-AI On the contrary, the garbage collector makes its living by concerning itself with obsolete cars.  Date: 30 September 1980 08:15-EDT From: Jonathan D. Taft To: BUG-NWS at MIT-AI Date: 30 SEP 1980 0205-EDT From: Moon at MIT-AI (David A. Moon) To: (BUG NWS) at MIT-AI The :draw-filled-in-chord message does not draw a chord. A chord is a line between two points on a circle and presumably a filled-in chord would be the area between a chord and the smaller of the two arcs it defines. The :draw-filled-in-chord message draws the area between two radii, which is called a section or something like that. We should rename the message once someone remembers what it is properly called by geometers. Why do we have this message at all ? Do we have a :draw-filled-in-packard or a :draw-filled-in-stutz message ? I see no need for the Lisp machines to concern itself with obsolete cars.  Date: 30 SEP 1980 0227-EDT From: Moon at MIT-AI (David A. Moon) To: (BUG NWS) at MIT-AI, DLW at MIT-AI The following messages are required to be handled by all streams, according to the manual and SI:STREAM-DEFAULT-HANDLER. Windows do not handle them. Probably we should add no-op methods for these, although there may be some that should be redefined not to be handled by all streams. :LINE-IN :CLEAR-OUTPUT :FORCE-OUTPUT :FINISH :CLOSE  Date: 30 SEP 1980 0205-EDT From: Moon at MIT-AI (David A. Moon) To: (BUG NWS) at MIT-AI The :draw-filled-in-chord message does not draw a chord. A chord is a line between two points on a circle and presumably a filled-in chord would be the area between a chord and the smaller of the two arcs it defines. The :draw-filled-in-chord message draws the area between two radii, which is called a section or something like that. We should rename the message once someone remembers what it is properly called by geometers.  Date: 30 SEP 1980 0158-EDT From: Moon at MIT-AI (David A. Moon) To: (BUG NWS) at MIT-AI %DRAW-RECTANGLE-CLIPPED uses negative x and y bitposes to mean something magic with wrap-around. The (STREAM-MIXIN :DRAW-RECTANGLE) method simply calls %DRAW-RECTANGLE-CLIPPED with arguments translated to inside coordinates. This means it will do completely the wrong thing for rectangles that stick out to the left or the top and need to be clipped. I've made a number of small changes to the graphics methods to make them more consistent, but I don't want to change this on my own because it may be incompatible. Should %DRAW-RECTANGLE-CLIPPED be changed or should it simply not be called in this case?  Date: 27 SEP 1980 1512-EDT From: HIC at MIT-AI (Howard I. Cannon) To: (BUG NWS) at MIT-AI In the new process system, either because it is faster or slower (?), if you double click on a lisp listener you manage to get TWO system menus. Usually they are right on top of each other, causing bizzare behaviour. Sometimes, they are a few pixels off, and it looks even more wierd. Why didn't this happen before? What should we do about it now?  Date: 25 September 1980 15:09-EDT From: Daniel L. Weinreb Sender: DLW at CADR1 at MIT-AI To: BUG-NWS at MIT-AI In the version of NWS on system 44.3, with microcode 692, on LISP Machine One: I just finished sending some mail from Zmail. The mouse was sitting near the bottom of the main mail-typein editor window. I then hit End to send the mail, and so the main Zmail display returned. The mouse now found itself sitting on the right-hand side of the bottom edge of the window holding the message I was reading, and so it turned itself into a fat down-array, and scrolled the window by one line. This is losing: I didn't ask for the screen to be scrolled, by any stretch of the imagination. The mouse ought to come up as a fat arrow, but it should not scroll the window unless I actively move it down some.  Date: 25 September 1980 03:36-EDT From: Daniel L. Weinreb Sender: DLW at CADR6 at MIT-AI To: BUG-NWS at MIT-AI In the version of NWS on system 44.3, with microcode 692, on LISP Machine Six: I had just sent some mail from ZMAIL, and while ZMAIL was thrashing around trying to restore the regular summary-and-messge display, I typed System E. The editor frame came up on my screen. So I typed some commands, and the system magically made the ZMAIL frame reappear on my screen, and ZMAIL promptly barfed at the commands I had typed. I can understand what might cause this, but it is DAMNED confusing.  Date: 25 September 1980 00:10-EDT From: Daniel L. Weinreb Subject: Do It, Abort, Exit To: MMCM at MIT-AI cc: BUG-NWS at MIT-AI Date: 24 September 1980 21:07-EDT From: Mike McMahon Sender: MMcM at CADR6 at MIT-AI I have made the change over to this standard, with some special exemptions: Done hybrid of do it and exit, for definition mode, where each command really has an immediate effect, but there is also an overall goal. Quit leave this program context. i think these are more meaningful, do people think them likely to be confusing? I guess I don't understand this exactly. For the Done case about, how about saying "Do It and Exit" explicitly? I don't understand the contexts here so it is hard to judge whether they are likely to be confusing. It sure would be nice to reduce this vocabulary. Just where are you using these?  Date: 24 September 1980 21:07-EDT From: Mike McMahon Sender: MMcM at CADR6 at MIT-AI Subject: Do It, Abort, Exit To: DLW at MIT-AI cc: BUG-NWS at MIT-AI I have made the change over to this standard, with some special exemptions: Done hybrid of do it and exit, for definition mode, where each command really has an immediate effect, but there is also an overall goal. Quit leave this program context. i think these are more meaningful, do people think them likely to be confusing?  Date: 23 September 1980 23:50-EDT From: Daniel L. Weinreb Sender: DLW at CADR8 at MIT-AI Subject: Do It, Abort, Exit To: BUG-NWS at MIT-AI I prefer Moon's suggestion: Do It do what I have told you to do through a series of commands Abort don't do anything Exit leave this mode, for things where it does the operations as you give them rather than buffering them up til the end Done and Quit should not be used at all as they are ambiguous. "Done" might either mean Do It or Exit; it is not clear which, and these are really different things. Similarly, Quit might mean either Abort or Exit, and these are also different things. I don't think any of Do It, Abort, or Exit are reasonably misinterpretable.  Date: 23 September 1980 22:36-EDT From: Mike McMahon Sender: MMcM at CADR3 at MIT-AI To: MOON at MIT-AI cc: DLW at MIT-AI, BUG-NWS at MIT-AI Date: 23 SEP 1980 2156-EDT From: Moon at MIT-AI (David A. Moon) You broke the Split Screen operation in the system menu by changing "Do It" to "Done" in some places but not all places. This seems like a regressive change anyway, "Do It" should be used for things such as split screen where it accumulates things to do and doesn't do them until you tell it to. What I would like to see as the standard names for these things are: Do It do what I have told you to do through a series of commands Abort don't do anything Exit leave this mode, for things where it does the operations as you give them rather than buffering them up til the end Done and Quit should not be used at all as they are ambiguous. For now I will fix Split Screen to work and leave the menu operation called Done. But we should agree on what these operations are going to be called. I thought the proposed standard was: Done do what I have told you to do through a series of commands Abort don't do anything Quit leave this mode, for things where it does the operations as you give them rather than buffering them up til the end That being what the majority of programs (multiple choose, screen editor, zmail's many modes) were using. If you prefer the former set, i will change them as well.  Date: 23 September 1980 22:05-EDT From: Daniel L. Weinreb Sender: DLW at CADR8 at MIT-AI To: BUG-NWS at MIT-AI In the version of NWS on system 44.2, with microcode 692, on LISP Machine Eight: When you type System P, the thing that comes up looks really spastic. It has the message giving the summary of commands repeated about five times.  Date: 23 SEP 1980 2156-EDT From: Moon at MIT-AI (David A. Moon) To: MMCM at MIT-AI CC: (BUG NWS) at MIT-AI You broke the Split Screen operation in the system menu by changing "Do It" to "Done" in some places but not all places. This seems like a regressive change anyway, "Do It" should be used for things such as split screen where it accumulates things to do and doesn't do them until you tell it to. What I would like to see as the standard names for these things are: Do It do what I have told you to do through a series of commands Abort don't do anything Exit leave this mode, for things where it does the operations as you give them rather than buffering them up til the end Done and Quit should not be used at all as they are ambiguous. For now I will fix Split Screen to work and leave the menu operation called Done. But we should agree on what these operations are going to be called.  Date: 26 August 1980 21:04-EDT From: Mike McMahon Sender: MMcM at CADR6 at MIT-AI To: BUG-NWS at MIT-AI As of system 38, GRAPHICS-MIXIN is included as part of WINDOW. All the messages defined for that flavor take arguments in interior co-ordinates and most do clipping. It, STREAM-MIXIN and some of their lemen have been moved into the file LMWIN;STREAM.  Date: 22 AUG 1980 1824-EDT From: MMcM at MIT-AI (Mike McMahon) To: (BUG NWS) at MIT-AI In the version of nws on system 37.1, with microcode 684, on LISP Machine Seven: The SCROLL window is probably not worthy of that name. In both ZMAIL and PEEK, - if the top item is not 0, then nothing is displayed inside. - using the scroll-bar tells scroll-bar-draw to go off the screen. - the scroll bar can get stuck on, such that you need to move into it and back out again for it to turn off.  MOON@MIT-ML 08/19/80 15:36:17 Re: Selection To: (BUG NWS) at MIT-ML I think our problems with selection come from the fact that we are using selection both for windows and for programs (what were called "jobs" once). Problems occur when one window unmodularly selects a window belonging to another program, e.g. the bug that used to exist with supdup selecting the mini-buffer when you exited. Selection should be hierarchical, but (IMPORTANT!) it should not exist at every level of the window hierarchy. There should be the concept of a selection level; there is one at the top (if there was a window which was the superior of every screen the top level would be associated with it), and a frame that represents a program (e.g. the Zmacs frame, the drawing-program frame, the inspector frame) can have selection-level mixed in to it. A selection level has to have complete control over selection relations among its inferiors. Each selection level only knows as selectable windows the next selection levels down. The variable TV:SELECTED-WINDOW is a cache on all this; you compute its value by starting at the top selection level and following selected sub-levels until you get to a terminal window. Note that selection-levels don't control just their immediate inferiors, but all inferiors to all levels until you get to another selection level. This is important so that a program can use several levels of window hierarchy itself. I think this notion of selection-levels is what the :ALIAS-FOR-SELECTED-WINDOWS message is trying to implement. The :SELECT message is being used for three things and needs to be split into at least two messages. One is the message you send to a window to make it get selected with respect to the next selection-level up (select within program). Another is the message you send to a window to make it and all its superior selection-levels get selected; mouse-selection uses this for example. The third is the message you put daemons on; I guess it gets sent when TV:SELECTED-WINDOW is setq'ed to a window. This needs some more thought. There are similar issues with the :DESELECT message. Each selection-level needs to have its own history of previously-selected windows, used to find the new selected window at that level when something is explicitly deselected (possibly indirectly through :set-status or :deactivate). This history has to be separate at each level for modularity of programs, and so that switching between programs does not interfere with the stack-like nature of these histories. We don't have to decide whether to put a window into this history, we simply put in any every window that actually gets selected. This history doesn't need to be pre-loaded when a window is activated. When computing the menu of selectable windows, you map over all exposed windows but each selection-level controls the mapping over its inferiors; some will want to map over their inferiors, some will want to just put themselves into the menu, and some will want to return a canned alist or an alist of just certain of their inferiors. Now we come to the other use of selection, which is for selecting programs via the esc-s and system keys. I am not completely sure, but I believe this should have a completely separate history buffer, and should decide when a window goes in it by something other than :NAME-FOR-SELECTION. (I'm not sure whether a message or a mixin.) There needs to be yet a 3rd history buffer which SYSTEM uses to circulate through a ring of windows of the same type, to get rid of the present anomaly about whether the system key makes the current window most-recently or least-recently used. The programs history buffer is the one that can be preloaded with a window when it is activated. There is also the issue of auto-selection by the screen-manager. I'm not sure whether this should be selection of windows or of programs, and what criterion it should use to decide whether a window is selectable. There is a moderate incompatible change in here, but I think we should do it. It needs considerably more thought first, but I think these are the right lines to proceed on. This is actually not all that different from how things work now, it is really a reformulation of the present adhocery into a consistent whole. Mike, does this stimulate any thinking as to what is right?  Date: 16 AUG 1980 0115-EDT From: Moon at MIT-AI (David A. Moon) Subject: This is a hard one to fix To: (BUG NWS) at MIT-AI When a pop-up or momentary menu has a :set-item-list sent to it while it is exposed, it may grow itself by sending a :set-inside-size. The problem is that this can get an attempt to expose outside superior error. Somehow such windows should know to move themselves in this case. So far this seems to be programmed around by de-exposing and expose-window-near'ing around such a :set-item-list in user code, which is not such a great solution in my opinion. (expose-window-near knows not to try to expose things outside the superior.) Any suggestions for what the right philosophy for fixing this is? If said menu is popped up over the window the error handler is trying to type out on, you don't see your error. Probably the error handler should check if it is typing on a window and if so call a routine to see if it is locked and not going to get unlocked, e.g. locked by a temporary window which is itself locked by this process. If so it should decide to use the cold-load stream.  Date: 14 AUG 1980 2128-EDT From: MMcM at MIT-AI (Mike McMahon) To: (BUG NWS) at MIT-AI What good is a DYNAMIC-POP-UP-COMMAND-MENU? Or for that matter a lot of the combinations defined in the same place?  Date: 13 August 1980 11:55-EDT From: Howard I. Cannon To: MMcM at MIT-AI cc: BUG-NWS at MIT-AI Date: 13 August 1980 01:03-EDT From: Mike McMahon Sender: MMcM at CADR6 at MIT-AI To: BUG-NWS at MIT-AI In the version of NWS on system 36.2, with microcode 683, on LISP Machine Six: The error message in IO-BUFFER-UNGET is probably not necessary, it should just stick the new thing into the io-buffer and back up the pointer if it doesn't match. MOON and I discussed that when we first hacked it, and decided to put the error message in. I have no gross objections to removing it, though I thought you were not allowed to untyi anything but the last thing you tyi'ed.  Date: 13 August 1980 01:03-EDT From: Mike McMahon Sender: MMcM at CADR6 at MIT-AI To: BUG-NWS at MIT-AI In the version of NWS on system 36.2, with microcode 683, on LISP Machine Six: The error message in IO-BUFFER-UNGET is probably not necessary, it should just stick the new thing into the io-buffer and back up the pointer if it doesn't match.  Date: 12 AUG 1980 2319-EDT From: Moon at MIT-AI (David A. Moon) Subject: incompatible change notification To: (BUG NWS) at MIT-AI I flushed the third argument to TV:MENU-CHOOSE, which no one in the system was using, and changed it to a near-mode argument like the other choosing things take. It figures out what superior to put it under based on the near-mode.  Date: 12 AUG 1980 2304-EDT From: Moon at MIT-AI (David A. Moon) To: (BUG NWS) at MIT-AI tv:peek-chaos-hostat should either call the STATUS-answer-understanding routine in CHSAUX or should be updated to understand the current format.  Date: 12 AUG 1980 1407-EDT From: JERRYB at MIT-AI (Gerald R. Barber) To: (BUG NWS) at MIT-AI In system 36.2, with microcode 683, on LISP Machine Four: Selecting ANY on the window creation menu then typing Z to the request for a flavor name causes the requesting window to go away but also causes a "FLAVOR NAME WAS T" error. Since the new window system predominates these days is there any reason for having two bug lists anymore, ie BUG-NWS and BUG-LISPM?  Date: 12 AUG 1980 0815-EDT From: HIC at MIT-AI (Howard I. Cannon) To: (BUG NWS) at MIT-AI I fixed the off-by-1 scroll bug in the source, and also got rid of the bogus :SCROLL-TO method which was being shadowed anyway. A sever case of brain rot there...  Date: 12 August 1980 08:00-EDT From: Howard I. Cannon Subject: selectable windows To: MOON at MIT-MC cc: BUG-NWS at MIT-MC Probably we've finally started paying for the mistake of using the :name-for-selection message for too many different things. Ok, what should we do about it? This really needs to get fixed, since it is a bit wierd to have each editor appear twice in the select menu. It's not clear to me how the system is supposed to handle such things. Perhaps we need a message to a window which says: return a list of your selectable inferiors. Then normal windows would return themselves (based on the current criteria, of course), and then send this message to all inferiors and nconc the results. The Zwei frame would do the same, but not include itself. This seems like a kludge, but I'm not sure where else to embed the knowledge.  Date: 11 AUG 1980 2148-EDT From: MMcM at MIT-AI (Mike McMahon) Subject: notification in the editor To: DHD at MIT-AI CC: (BUG NWS) at MIT-AI So far as i know and can reproduce, the editor never uses pop-up notification. Could you please tell us under what circumstances it happens to you?  MOON@MIT-MC 08/11/80 20:31:14 Re: selectable windows To: (BUG NWS) at MIT-MC Date: 11 AUG 1980 0209-EDT From: HIC at MIT-AI (Howard I. Cannon) Sent-by: TFT at MIT-AI To: (BUG NWS) at MIT-AI The code for finding selectable windows goes through the specified superior and all inferiors to all levels, and returns a list of all windows with names for selection. In system 36.2, this causes each editor to appear twice. I don't think that going down all levels is right, though, and suggest that we change it to just look at immediate inferiors of the specified superior (function SELECTABLE-WINDOWS in BASWIN). I don't think that this would break anything, and I think that it is more intuitivly correct. This would cause the following error. If you had a frame with several selectable panes, it would show you only the frame's selected-pane. The bug is not that it shows you inferiors of a frame but that it shows you the frame itself. Probably we've finally started paying for the mistake of using the :name-for-selection message for too many different things.  Date: 11 August 1980 14:09-EDT From: Mike McMahon Sender: MMcM at CADR4 at MIT-AI To: BUG-NWS at MIT-AI In the version of NWS on system 36.2, with microcode 683, on LISP Machine Four: There is an off by one error in the SCROLL window's scroll bar handling. ':SCROLL-TO (SHEET-NUMBER-OF-INSIDE-LINES) ':RELATIVE puts the bottom line on the top line, it should put it just off the screen. ':SCROLL-TO 6 ':ABSOLUTE puts the sixth line at the top of the screen, it should put line # 6 (the seventh line) there.  Date: 11 AUG 1980 0209-EDT From: HIC at MIT-AI (Howard I. Cannon) Sent-by: TFT at MIT-AI To: (BUG NWS) at MIT-AI The code for finding selectable windows goes through the specified superior and all inferiors to all levels, and returns a list of all windows with names for selection. In system 36.2, this causes each editor to appear twice. I don't think that going down all levels is right, though, and suggest that we change it to just look at immediate inferiors of the specified superior (function SELECTABLE-WINDOWS in BASWIN). I don't think that this would break anything, and I think that it is more intuitivly correct.  Date: 10 AUG 1980 1407-EDT From: DHD at MIT-AI (David Hodgson Dennis) Subject: Postscript to previous message To: (BUG NWS) at MIT-AI Using my program, i got a notification about the message I sent to bug-nws; strangely enough, @i[that] notification was handled "correctly". Could this be a ZWEI bug instead? (I'm not resending that message to bug-zwei because I think most people on bug-zwei are on bug-nws too) - dhd  Date: 10 AUG 1980 1401-EDT From: DHD at MIT-AI (David Hodgson Dennis) Subject: Notification To: (BUG NWS) at MIT-AI In the version of nws on system 34.1, with microcode 678, on LISP Machine Seven: I have written a set of functions using the notification feature of the New Window System. Unfortunately, when a notification window appears, it is immediately selected, and you cannot ignore it; you have to deselect it, which I consider to be a great loss. In addition, sometimes [ESC]S will not work; it will often not select the previous window selected. For example, sometimes I'm in the editor and get a notification; I deselect the window and wind up in a LISP Listener. ZWEI now uses the pop-up notification mixin (or so I gather), instead of just typing the notification in the echo area. I consider this to be a great loss, as I often do not wish to interrupt my typein to the editor to respond to a notification. I would suggest that pop-up notifications should be handled in the following way: A small window-without-label should appear and dissappear within ten seconds after a character is typed on the screen. This would provide for additional user convenience in that he would not have to interrupt the task at hand to deal with a recalcitrant window. In addition, it would ensure that few notifications would be lost. Another bug is that notifications are lost when you transfer between two windows. For example, when I am in a LISP listener and go to the editor (using the (ed) function), I will lose any notifications I get during the window change. - dhd  Date: 9 August 1980 02:10-EDT From: Howard I. Cannon To: Moon at MIT-AI cc: BUG-NWS at MIT-AI Date: 8 August 1980 22:29-EDT From: David A. Moon To: BUG-NWS at MIT-AI Why do most exception handlers check whether the flag bit is on, and not do anything if it isn't? Is this for a reason? I don't see any obvious way they would accidentally get called when they shouldn't be, and it is probably a useful user feature to be able to send a :MORE-EXCEPTION message and have one happen, and it's a crock to have to set the flag first for that to work. I'm not really sure, but I guess this was to allow one handler to handle multiple exceptions, or for an execption to go away due to some timing screw or....basically, some bad idea. I don't think that flushing those checks would damage anything.  Date: 8 AUG 1980 2229-EDT From: Moon at MIT-AI (David A. Moon) To: (BUG NWS) at MIT-AI Why do most exception handlers check whether the flag bit is on, and not do anything if it isn't? Is this for a reason? I don't see any obvious way they would accidentally get called when they shouldn't be, and it is probably a useful user feature to be able to send a :MORE-EXCEPTION message and have one happen, and it's a crock to have to set the flag first for that to work.  Date: 8 AUG 1980 1417-EDT From: MMcM at MIT-AI (Mike McMahon) To: (BUG NWS) at MIT-AI In the version of nws on system 36.0, with microcode 682, on LISP Machine Six: The who-line run-state does not get updated in the case of a failing (beep'ing) system key.  Date: 7 AUG 1980 0330-EDT From: Moon at MIT-AI (David A. Moon) Subject: Status of system 35 To: (BUG NWS) at MIT-AI System 35.0 has millions of bugs. MMcM and I have fixed all of them (well, most of them) in the source. A new cold-load needs to be generated due to a bug in the cold-load generator which I have fixed. Instead of making a new system like I should have, I've spent the whole night putting infinite hair into Split Screen. It still isn't done but it's in reasonable shape to install at this point. Actually, that wasn't such a waste of time since I found and fixed several hundred bugs in the process. Before making a new system it's important to recompile-world, not just the TV package, due to wide distribution of bugs (e.g. in CHSNCP). If no one else makes a new system I will tomorrow.  Date: 7 AUG 1980 0158-EDT From: Moon at MIT-AI (David A. Moon) Subject: Gratuitous change notification To: (BUG NWS) at MIT-AI I changed menus to use top-box-label-mixin rather than top-label-mixin since I thought that having the label outside the box looked very ugly on pop-up menus.  Date: 7 AUG 1980 0035-EDT From: Moon at MIT-AI (David A. Moon) To: (BUG NWS) at MIT-AI SYSTEM-WINDOW-ADD-TYPE simply ignores you if you evaluate it when the type definition, for instance the creation function, has been changed. It should of course rplac the appropriate things in its data structure.  Date: 6 AUG 1980 1759-EDT From: MMcM at MIT-AI (Mike McMahon) To: (BUG NWS) at MIT-AI The system should probably arrange to create a PEEK window during initialization and activate it. Always, when something is running wild it mamages to stop before SYSTEM P has done its thing.  Date: 6 August 1980 16:11-EDT From: Mike McMahon Sender: MMcM at CADR9 at MIT-AI Subject: System 35.0 / ucadr 680 To: MOON at MIT-AI cc: BUG-NWS at MIT-AI Date: 6 AUG 1980 0259-EDT From: Moon at MIT-AI (David A. Moon) I have given these very little testing, but I will leave them installed on CADR's 6 and 9 before I go. They seem to work well enough. KBD-GET-IO-BUFFER was returning the value of WHO-LINE-RUN-STATE-UPDATE causing errors if you had typed ahead over a selection change. During loading the editor frame exposed itself even though there was already a lisp listener exposed. I know it was exposed because it was blinking. The most likely theory is that something decided to select it. I tried to reinitialize it manually and it did not expose itself. Immediately after cold booting if you type system E it fails to find the editor frame that is already there, but runs for a long time then displays something labelled ZMACS-WINDOW-1 which is the full size of the screen. At this point if you go back to the lisp listener and type (ED) it dies because the command loop's window thinks that its frame is the main screen. Probably the TV:*SYSTEM-KEYS* entry did not get updated. Mike, could you fix this? The real problem was that frame's did not have :name-for-selection since we didn't think to add a primary method (that could be shadowed by select-mixin) when the wrapper there was flushed.  Date: 6 AUG 1980 0259-EDT From: Moon at MIT-AI (David A. Moon) Subject: System 35.0 / ucadr 680 To: (BUG NWS) at MIT-AI I have given these very little testing, but I will leave them installed on CADR's 6 and 9 before I go. They seem to work well enough. Here are some bugs. During loading the editor frame exposed itself even though there was already a lisp listener exposed. I know it was exposed because it was blinking. The most likely theory is that something decided to select it. Upon cold booting often but not always the first character typed (capital T) disappears. Immediately after cold booting if you type system E it fails to find the editor frame that is already there, but runs for a long time then displays something labelled ZMACS-WINDOW-1 which is the full size of the screen. At this point if you go back to the lisp listener and type (ED) it dies because the command loop's window thinks that its frame is the main screen. Probably the TV:*SYSTEM-KEYS* entry did not get updated. Mike, could you fix this? On the other hand typing (ED) immediately upon cold booting does the right thing except that garbage is displayed for the usual reason (the editor was the exposed window when the band was saved.) There are a bunch of changes to the Split Screen stuff which I wanted to do in this world but didn't have time for. Also I plan to flush Layouts from the system menu unless there are objections (sorry, Perky Pat). This will happen tomorrow I guess.  Date: 4 August 1980 15:57-EDT From: Mike McMahon Sender: MMcM at CADR2 at MIT-AI To: BUG-NWS at MIT-AI The SYSTEM-WINDOW facilty is much less convenient to define and use than WITH-RESOURCE. Either its non-standard syntactes should be improved or the resource stuff should be extended enough to filter out non-usable items from the resource.  Date: 4 AUG 1980 0318-EDT From: DLW at MIT-AI (Daniel L. Weinreb) Subject: User Interface: More flaming along the same lines. To: (BUG NWS) at MIT-AI MOON@MIT-MC 08/04/80 00:37:02 Date: 3 AUG 1980 2052-EDT From: HIC at MIT-AI (Howard I. Cannon) To: (BUG ZWEI) at MIT-AI In system 34.1, with microcode 678, on LISP Machine Two: ^Z'ing out of the editor doesn't seem to bury the frame. Why should it? This is another example of what my last flaming message was about. The old EINE paradigm of entering with "(ed)" (the special-purpose command from Lisp to the editor) and exiting with "^Z" (the special-purpose return from the editor to whatever called it) should be replaced by a global command structure for invoking programs in general. There is nothing wrong with a "select the previous program" command like the DDT ^H command.  MOON@MIT-MC 08/04/80 00:49:17 Re: Every program having every command in it To: DLW at MIT-AI CC: (BUG NWS) at MIT-MC Well, the system key exists for rapid switching of programs. But it will always be the case that switching programs is slower and has more mental overhead than just giving a command, and sometimes you have to trade off theoretical cleanliness for ease of use. But indeed the right thing would be to switch from zmail to the file-utility program we don't have when I wanted to View a File.  Date: 3 AUG 1980 0548-EDT From: DLW at MIT-AI (Daniel L. Weinreb) To: (BUG NWS) at MIT-AI I saw a bug-nws message a while ago in which Moon asked for a View File command in ZMAIL. Somehow, I have visions of a system in which every program has a command to call every other program. I mean, what if I am in the Lisp-Machine-equivalent of SUDS and I want to view a file, or read my mail? What if I am in Zmail and I want to design a new multiplexer chip definition? I think there should be a general command structure so that you can get any program when you want it, and that things like View File commands in ZMAIL should be discouraged. This applies to Zmacs commands that invoke mail reading and sending and INFO, too, unless it is felt that Emacs compatibility is important here; I don't think it is. It makes sense to do things this way in Emacs because a whole set of programs are so designed that they must live in the dyanamically linked, TECO-based world that Emacs provides in lieu of ITS; but we certainly don't have that problem in the Lisp Machine. Right now the system menu seems to be the de-facto way to invoke programs, so maybe the View File command should really be in the system menu. The thing is, that menu is going to get very big some day. Especially if it needs to hold "View File", "Rename File", "Delete File", "Create Link" and so on. I guess you could have a powerful directory editor subsystem that is always used to do these things, but that might be obnoxious (and its 17-paned window might take > 15 seconds to appear...). Anyway, enough for now about this, I realize it is not a simple issue.  Date: 1 AUG 1980 2313-EDT From: Moon at MIT-AI (David A. Moon) To: (BUG NWS) at MIT-AI When EXPOSE-WINDOW-NEAR calls MOVE-WINDOW-NEAR-RECTANGLE, it warps the mouse to where the window is. This is sometimes desired and sometimes not; I'm not sure just why it does this or what will break if I change it, so I'll leave it alone more or less and put in a kludge for the benefit of Split Screen. But someone who knows more about this should look into it sometime.  Date: 1 AUG 1980 2334-EDT From: Moon at MIT-AI (David A. Moon) To: (BUG NWS) at MIT-AI Is it a bug or a misfeature that typing esc c-clr while temporary windows are on the screen smashes the bits of the window underneath, i.e. unlocks it without first restoring its bits?  Moon@MIT-MC 08/01/80 04:35:28 To: (BUG NWS) at MIT-MC In the version of NWS on system 34.1, with microcode 678, on LISP Machine Six: Hitting CALL while in ZMAIL arrests the process but doesn't do anything else. But then something is locked so that other things such as creating a lisp listener from the system menu hang. esc c-clr clears but this needs investigation. It is still the case that sometimes an exposed unselected editor window can get its parenthesis blinker stuck in the on state, so that a parenthesis turns into a space. The extra blinkers should never allow themselves to get into the on (as opposed to blink) state. (I think I've seen the mouse character blinker do this, too, although not in system 34.)  Moon@MIT-MC (Sent by Moon at CADR6@MIT-MC) 08/01/80 04:30:03 To: MMCM at MIT-MC CC: (BUG NWS) at MIT-MC Well, it didn't actually blow out, but it doesn't work. Trivial things first. I would be willing to give up several columns of subject to get the date in the summary. I consider dates in the summary essential. Times may be omitted. The symbol ZMAIL should be global. It leaves the mail file open for a long time while it ponders its data structure; it should rename it to OMAIL as soon as it starts reading it, and should remember to delete that OMAIL file after the first time it writes back the RMAIL file. Also when starting up it should look for an OMAIL file left over from a previous invocation that failed to complete. This would minimize both loss and duplication of messages. There should be a View File command; I very frequently type x View File in Rmail when someone sends me a message asking me to look at a certain file. Probably also I should be able to type meta-altmode and get a 1-line Lisp listener. When viewing a message more than one screen long, there is no indication that there may be more to the message. It should say "--more--" or words to that effect. However, the main problem is that it is completely incapable of dealing with large mail files. This is not just a matter of not enough memory. My rmail file contains 382 messages, which is not all that many (it's been pruned within the last month.) Zmail took over 15 minutes to start up and start listening to the tty, because it was parsing my entire rmail file into SCROLL data structure for the summary. It is not reasonable to do this for the entire file when only a small part of the summary is likely to be looked at. By the way during this parsing my MAIL file was left open (maybe my RMAIL file was too, I don't know) which is probably a bug. Furthermore typing any keyboard command (even the space to go to the next screen of a message) takes over a minute to execute. I didn't find out what it was doing during that time but I assume it was hacking with the data structure for the summary since I don't know what else it could have been doing. I didn't try any of the hairy commands, under the circumstances.  Date: 1 AUG 1980 0032-EDT From: MMcM at MIT-AI (Mike McMahon) To: (BUG NWS) at MIT-AI In system 34.1, some bugs in the new "Any" option: If the flavor has never been instantiated before, SI:FLAVOR-DEPENDS-ON-ALL is not yet setup, so GET-WINDOW-TYPE-FROM-KEYBOARD barfs. The window for reading Any in Split Screen pops up over the menu. It should position itself aesthetically like the Existing Window menu.  Date: 31 July 1980 22:54-EDT From: Mike McMahon Sender: MMcM at CADR6 at MIT-AI To: BUG-NWS at MIT-AI System 34.1 is installed on cadr-1 and cadr-6. In addition to the changed noted before, i have loaded ZMAIL into this world. I would appreciate it if the more daring among you would try it out and let me have your comments.  Date: 31 July 1980 21:45-EDT From: Howard I. Cannon To: MMCM at MIT-AI cc: BUG-NWS at MIT-AI Date: 31 July 1980 21:23-EDT From: Mike McMahon To: BUG-NWS at MIT-AI The screen manager is still exposing the editor frame, although now at a time when its structures are consistent. Perhaps the only solution is to expose the initial lisp listener explicitly. I think that this is the right approach.  Date: 31 JUL 1980 2123-EDT From: MMCM at MIT-AI (Mike McMahon) To: (BUG NWS) at MIT-AI The screen manager is still exposing the editor frame, although now at a time when its structures are consistent. Perhaps the only solution is to expose the initial lisp listener explicitly.  Date: 31 July 1980 02:25-EDT From: Howard I. Cannon To: MMCM at MIT-AI cc: BUG-NWS at MIT-AI Date: 30 July 1980 19:40-EDT From: Mike McMahon To: BUG-NWS at MIT-AI the tv:without-screen-management in zwei:initialize-all-of-editor does not seem to have any effect. the screen manager still gets called after the window gets activated to autoexposed the inferiors of the frame, which bombs out because the editor datastructures have not been created yet. Fixed. There was a bug in TV:WITHOUT-SCREEN-MANAGEMENT  Date: 30 JUL 1980 1940-EDT From: MMCM at MIT-AI (Mike McMahon) To: (BUG NWS) at MIT-AI the tv:without-screen-management in zwei:initialize-all-of-editor does not seem to have any effect. the screen manager still gets called after the window gets activated to autoexposed the inferiors of the frame, which bombs out because the editor datastructures have not been created yet.  Date: 29 Jul 1980 2332-PDT From: Dan Weinreb Subject: feature, maybe To: bug-nws at MIT-AI While using the NWS that time at Xerox, I scribbled down that I thought it might be a useful feature to have a menu entry in Split Screen that means "no window at all"; that is, it allocates space where it would put a window, but actually doesn't put anything there. I guess the idea was to leave you with some screen space to do things with, like create new windows. On further thought I am not sure this is worth putting in, but why don't you guys decide.  Date: 29 July 1980 20:48-EDT From: Howard I. Cannon Subject: Horrible dropping of characters -- GOOD GRIEF! To: DHD at MIT-AI cc: BUG-NWS at MIT-AI, RMS at MIT-AI The bug you are experiencing with characters being dropped is due to your init file. Since you SETQ terminal-io of the current process to a window that is being used by another process, you have two processes reading from the same window, and which characters go where is completely random. You should flush the SETQ from your init file, and explicitly specify the window as a stream argument, or at most bind terminal-io for the duration.  Date: 29 JUL 1980 1927-EDT From: DHD at MIT-AI (David Hodgson Dennis) Subject: Horrible dropping of characters -- GOOD GRIEF! To: (BUG NWS) at MIT-AI CC: RMS at MIT-AI In the version of nws on system 32.2, with microcode 674, on LISP Machine Four: Several times during the use of cadrs one and four, I have seen it drop characters. For example, (describe foo) >>>>TRAP 14205 (TRANS-TRAP) The function DESE is undefined. While in the function SI:*EVAL  SI:LISP-TOP-LEVEL1  SI:LISP-TOP-LEVEL  While this is an extreme example, the dropping of characters -- especially when there is no indication (in the echoing) that something has gone wrong -- is a very serious occurence. This will almost always happen when I type CALL to get from the editor into a lisp listener and am foolish enough to type ahead. However, as in the previous example, it seems to happen fairly often even when I am not switching windows. This is in part because of a heavy background process load, but if the big timesharing systems can do it right, then surely you could!  MMcM@MIT-MC 07/29/80 16:11:25 To: (BUG NWS) at MIT-MC I have added another argument to %DRAW-LINE, which is whether or not to draw the second endpoint. All the uses of it i could find have been fixed.  Date: 28 JUL 1980 2243-EDT From: Moon at MIT-AI (David A. Moon) To: (BUG NWS) at MIT-AI In the version of nws on system 32.3, with microcode 674, on LISP Machine Nine: I was doing m-x View File and randomly waving the mouse around to help me point out things in the file being viewed. After view file got to a more break, the mouse process was frozen in an output hold on zmacs-window-1 (not the view window but the editor window underneath) from trying to set the visibility of a blinker. I don't think I moved the mouse anywhere near any window boundaries.  MOON@MIT-MC 07/28/80 16:15:21 To: (BUG NWS) at MIT-MC Date: 27 JUL 1980 2226-EDT From: MMcM at MIT-AI (Mike McMahon) To: (BUG NWS) at MIT-AI In the version of nws on system 32.3, with microcode 674, on LISP Machine Six: Split screen of two windows only exposes the top window. Fixed in the source.  MOON@MIT-MC 07/28/80 15:50:16 Re: Name of the screen To: (BUG nws) at MIT-AI, acw at MIT-AI, dlw at MIT-AI I have renamed the main screen from CPT-SCREEN to MAIN-SCREEN, both in the variable that holds it and in the name of the sheet as seen in such places as "Edit Screen"'s menu of screens. This change is in the source only.  MOON@MIT-MC 07/28/80 12:32:10 Re: Window editing To: DLW at MIT-AI CC: (BUG NWS) at MIT-MC DLW@MIT-AI 07/28/80 01:23:25 Re: P.S. To: MOON at MIT-MC More about that window-editing operation: suppose there is an existing but invisible (buried) window and you would like to put it up in a certain place. I think (shows how much I know) that now you ahve to bring it back up, in the same part of the screen where it used to be, and then reshape it to where you want to be. This is (a) a bit clumsy, and (b) requires an extra redisplay of the window which (let's face it) is slow. An operation which says "bring up this window and shape it like this", where right after you mouse the menu item you proceed to define the corners, might be good. If this suggestion makes sense in the context of the current state of the NWS you might forward it to BUG-NWS. We could have that but the problem is you would need a variant of each of several commands to do that. Maybe there could be a thing which "modified the next command".  Date: 28 JUL 1980 0208-EDT From: DLW at MIT-AI (Daniel L. Weinreb) Subject: Naming philosophy To: (BUG NWS) at MIT-AI When going into the screen editor and given a choice between the "CPT" and the "INSPECTOR-FRAME-1" (or whatever), several people thought it was weird that the black-and-white screen was being identified by its manufacturer. This may seem niggling, but I think it is worth adopting some better naming to avoid this, particularly since I've been told that other companies may be supplying monitors in the future.  MOON@MIT-MC 07/27/80 22:58:09 To: (BUG nws) at MIT-AI CC: dlw at MIT-AI Date: 26 JUL 1980 0405-EDT From: DLW at MIT-AI (Daniel L. Weinreb) Subject: Feature NWS To: (BUG NWS) at MIT-AI Today on a Lispm, I had the screen split three was between windows A, B, and C, and after some hacking decided I now wanted D in the middle instead of B. You currently have to go through completely re-splitting the screen, with two menu-selections each to get A and C in there. A version of split screen that started with the current layout and let you edit it might be good. Also or alternatively, a command to something saying "put this window where that one currently is" might be good. You wanted the screen editor "expose (menu)" operation (which probably doesn't exist in the ridiculously antique system they run at PARC for some reason). However, it might well be nice to have a screen editor operation which set the edges of one window from the edges of another. You can do this with Reshape if you have a very accurate hand with the mouse, or you can do it with Reshape followed by Expand Window. There is also a "function", (tv:expose-window-near window1 `(:window ,window2)), which gives window1 the same edges as window2 and exposes it. It isn't documented yet. Note, Dan, that you usually want to use Edit Screen rather than Split Screen. I don't know of any reasonable way to combine the two into one.  Date: 27 JUL 1980 2226-EDT From: MMcM at MIT-AI (Mike McMahon) To: (BUG NWS) at MIT-AI In the version of nws on system 32.3, with microcode 674, on LISP Machine Six: Split screen of two windows only exposes the top window.  Date: 27 July 1980 16:16-EDT From: Mike McMahon Sender: MMcM at CADR1 at MIT-AI Subject: selection and frames revisited To: BUG-NWS at MIT-AI In the version of NWS on system 32.3, with microcode 674, on LISP Machine One: Why is there a wrapper on :NAME-FOR-SELECTION provided by BASIC-FRAME that insists that there be a SELECTED-PANE? I use a frame that can itself be selected, and there is no way to get rid of that.  Date: 26 July 1980 15:28-EDT From: Mike McMahon Sender: MMcM at CADR1 at MIT-AI To: DLW at MIT-AI cc: BUG-NWS at MIT-AI Date: 26 JUL 1980 0406-EDT From: DLW at MIT-AI (Daniel L. Weinreb) In the highly obsolete system at PARC (29.something), if you split the screen and the first (not the second) window you ask for is PEEK, then when you say Do It, it puts up the Peek window and then goes into an infinite loop with "Activate" in the who line. Someone should make sure the current system has this fixd. Yes, this has been fixed for a long time.  Date: 26 JUL 1980 0411-EDT From: DLW at MIT-AI (Daniel L. Weinreb) To: (BUG NWS) at MIT-AI In the crufty old Parc system, Peek appears to have two modes for displaying what the old ROOM function used to do. One is Areas and the other Memory or something. I got highly confused by getting into the wrong one and wondering why it wasn't mouse-sensitive (which damperd the quality of my demo...). Is the one that is not mouse sensitive really a useful thing? It looked like an older, weaker thing, or something.  Date: 26 JUL 1980 0406-EDT From: DLW at MIT-AI (Daniel L. Weinreb) To: (BUG NWS) at MIT-AI In the highly obsolete system at PARC (29.something), if you split the screen and the first (not the second) window you ask for is PEEK, then when you say Do It, it puts up the Peek window and then goes into an infinite loop with "Activate" in the who line. Someone should make sure the current system has this fixd.  Date: 26 JUL 1980 0405-EDT From: DLW at MIT-AI (Daniel L. Weinreb) Subject: Feature NWS To: (BUG NWS) at MIT-AI Today on a Lispm, I had the screen split three was between windows A, B, and C, and after some hacking decided I now wanted D in the middle instead of B. You currently have to go through completely re-splitting the screen, with two menu-selections each to get A and C in there. A version of split screen that started with the current layout and let you edit it might be good. Also or alternatively, a command to something saying "put this window where that one currently is" might be good.  Date: 24 JUL 1980 1905-EDT From: DLW at MIT-AI (Daniel L. Weinreb) Subject: not a bug, just a very minor anecdote To: (BUG NWS) at MIT-AI While at PARC the other day, I wondered what algorithm Split Screen used to split the screen after you had more than six windows. Wel, I found out, it's not too interesting. But I randomly kept clicking the button and putting more and more windows into the little window display. Howard told me to keep going, and sure enough I saw the hack where the text gets turned into line segments. But, unexpectedly, I kept going, until I had the entire little screen map fully solid black (and a few more for good measure), and (holding my breath) I told it to Do It. Howard expected the machine to die, but in fact it started putting up lots of little windows, one at a time (rather slowly), each about 7 or 8 pixels high. It would have taken forever to finish, so I cold booted. It looked quite weird.  Date: 24 July 1980 14:01-EDT From: Mike McMahon Sender: MMcM at CADR7 at MIT-AI Subject: zmail To: BUG-NWS at MIT-AI, BUG-ZWEI at MIT-AI First note that ZMAIL has been moved into the ZMAIL; directory, since it kept crowding things in NZWEI;. Below are some random timings from on a machine with 256K. In general response is quite satisfactory in this mode, especially noticeable is the lack of paging in the mouse process when moving among different windows. What 128K 192K 256K Loading up 10-15 mins < 5 mins (ZMAIL) to TYI 4 secs 4 secs 1-2 secs Pop up filter frame, no change 5 secs 1 sec Pop up filter frame, changes 10 secs 7 secs 3 secs [FORM] 10 secs 7 secs 3 secs Into filter definition mode 45 secs 7 secs 5 secs Into reply mode 15 secs 7 secs 5 secs Grinding in definition mode 7 secs 3 secs < 1 sec Sorting messages and redisplay 5 secs 3 secs 1-2 secs Changing keywords and redisplay 3 secs < 1 sec  MOON@MIT-MC 07/23/80 15:28:16 Re: Creating a window for trace output To: DLW at MIT-AI CC: (BUG NWS) at MIT-AI (setq trace-output (tv:window-create 'tv:window ':edges-from ':mouse ':expose-p t)) But probably there should be a way to do this using the Split Screen menu operation. Also, that operation should provide the ability to edit the boundaries in the little image of the screen that appears to the left of the menu; I guess I'll work on this to take my mind off what I should be doing. In general tv:window is the most useful random flavor; it has all of the essential features including stream i/o, and doesn't have any specialized features such as editing, an automatically supplied process, specially formatted display, etc.  Date: 23 JUL 1980 0154-EDT From: DLW at MIT-AI (Daniel L. Weinreb) To: (BUG NWS) at MIT-AI There should be an option in the Create mouse item that lets you create a plain vanilla window, so that you can SETQ some stream to be that window and have output just appear on it. I don't know what FLAVOR I really want, but I do not want a Lisp Listener; that did the wrong thing to me today. I wanted to setq trace-output to a random window so that I could trace a ZWEI function and then edit some and see where it was called without messing up the display. In addition, the trace thing I wanted to do is probably generally useful in its own right and should somehow be installed somewhere somehow so that it is winning.  Date: 23 JUL 1980 0147-EDT From: JERRYB at MIT-AI (Gerald R. Barber) To: (BUG NWS) at MIT-AI Cadr9 is dead in the water, it won't even cold boot.  Date: 23 JUL 1980 0052-EDT From: Moon at MIT-AI (David A. Moon) To: (BUG NWS) at MIT-AI Somewhere in the process of switching selected windows it forgets to call who-line-run-state-update (the crock!), which also isn't called by the normal every 1 second updating of the who-line. This is why it sometimes gets stuck with a ridiculous state such as "Lock" in the wholine when it is clearly actually in TYI. (And Lock is the state of some other process which is no longer the "selected" one.)  Date: 21 JUL 1980 1619-EDT From: ACW at MIT-AI (Allan C. Wechsler) To: (BUG NWS) at MIT-AI In system 29.95 NWS, with microcode 669, on LISP Machine Three: At present, TERMINAL S, when given an argument greater than the total number of selectable windows, just does nothing. Shouldn't it beep or something? The user clearly made a mistake and should be told about it. ---Wechsler  Date: 21 JUL 1980 1538-EDT From: ACW at MIT-AI (Allan C. Wechsler) Subject: Move Multiple To: (BUG NWS) at MIT-AI The Move Multiple option of Edit Screen has a slight clumsiness in its user interface. Clicking Left Long at a feature is just the same as clicking Left at it, except that it also signals that the move should start. In other words, the feature clicked at is still added to or removed from the list of things to be moved, exactly as it is with Left Short. I think that the operations of selecting features to be moved and then deciding to move them are conceptually distinct, and should be invoked separately. This combination of adding or removing the last feature simultaneously with starting the move is a litle unintuitive. (Also, the long click is unconventional, but what do I know.) ---Wechsler PS: I don't completely understand the heuristics for deducing that wanting to move certain features implies a desire to move others.  Date: 20 JUL 1980 2129-EDT From: BAK at MIT-AI (William A. Kornfeld) To: (BUG NWS) at MIT-AI For the system menu instigated commands I would like to have SELECT and and the selecting part of LAYOUTS combined into one (presumably called SELECT). They are conceptually similar enough that I have on several occasions moused one when I really needed the other; I can't think of any argument for keeping them in 2 separate places.  Date: 20 July 1980 10:35-EDT From: Jonathan D. Taft To: Moon at MIT-AI cc: BUG-NWS at MIT-MC Date: 19 JUL 1980 2342-EDT From: Moon at MIT-AI (David A. Moon) To: (BUG NWS) at MIT-AI What do we want to do about the hardware bug that you can't flash a color screen? Should make the :BEEP message to the color screen do SOMETHING reasonable, maybe frob a big xor across it? If you implement this remember to supply barf bags for any users who get color sick.  Date: 20 JUL 1980 0104-EDT From: Moon at MIT-AI (David A. Moon) To: (BUG NWS) at MIT-AI In the version of nws on system 32.2, with microcode 674, on LISP Machine One: Calling the inspector from meta-altmode in the editor does not work because someone is not binding his streams properly, and it reads from the editor's typeout window rather than from its interaction pane.  Date: 19 JUL 1980 2342-EDT From: Moon at MIT-AI (David A. Moon) To: (BUG NWS) at MIT-AI What do we want to do about the hardware bug that you can't flash a color screen? Should make the :BEEP message to the color screen do SOMETHING reasonable, maybe frob a big xor across it?  Date: 19 JUL 1980 2216-EDT From: MMcM at MIT-AI (Mike McMahon) To: (BUG NWS) at MIT-AI CHOOSE-VARIABLE-VALUES' :STRING option doesn't quite work: if the string ever gets empty there is no way to select it again to change it.  Date: 19 JUL 1980 1713-EDT From: MMcM at MIT-AI (Mike McMahon) To: (BUG NWS) at MIT-AI In system 32.2, with microcode 674, on LISP Machine Six: Menu items are now clipped so as to leave the full MENU-INTERWORD-SPACING between items, even when the full item would still fit with less spacing. Although i could make that constant an instance variable of the menu itself, it seems that this behaviour is generally undesirable.  Date: 19 JUL 1980 1308-EDT From: BAK at MIT-AI (William A. Kornfeld) To: (BUG ZWEI) at MIT-AI, (BUG NWS) at MIT-AI In system 32.1, microcode 674, on CADR1: In a Zwei buffer, if text in font CPT-TR10I is followed by text in font CPTFONT on the same line, the display routines overprint the text in CPTFONT on top of the text in CPT-TR10I. This does not happen when the order of appearance of the two fonts is reversed.  Date: 19 JUL 1980 1255-EDT From: BAK at MIT-AI (William A. Kornfeld) To: (BUG ZWEI) at MIT-AI, (BUG NWS) at MIT-AI In system 32.1 In incremental searches the characters ALTMODE and RUBOUT do not have their command significance; instead they are merely appended to the search string.  Date: 18 JUL 1980 1535-EDT From: MMcM at MIT-AI (Mike McMahon) To: (BUG NWS) at MIT-AI There is some circle drawing stuff that i unearthed and fixed for the NWS in MMCM;GSMIX. It (and perhaps things like (STREAM-MIXIN :DRAW-TRIANGLE)) should probably be put someplace.  Date: 18 July 1980 11:52-EDT From: Mike McMahon Subject: there could be a variable to turn this mode on To: BUG-NWS at MIT-AI cc: RICH at MIT-AI Date: 18 JUL 1980 1120-EDT From: RICH at MIT-AI (Charles Rich) To: (BUG ZWEI) Re: Shift Lock In system `29.95 NWS, with microcode 669, on LISP Machine Eight: It would be nice if, when CapsLock key is set, that the Shift key would temporarily shift to lower case when depressed. Similarly, in Electric Shift Lock mode, the Shift key should shift back to upper case.  Date: 17 JUL 1980 2239-EDT From: MMcM at MIT-AI (Mike McMahon) Sent-by: ___034 at MIT-AI To: (BUG NWS) at MIT-AI Whoever decides whether or not a TV:MULTIPLE-CHOOSE type window has scrolling should also reset TOP-ITEM to 0. If a resource gets reused and was scrolled last time, it starts out with the interesting stuff off the screen.  MOON@MIT-MC 07/16/80 18:27:14 To: (BUG NWS) at MIT-MC Hacking the disk of a 31.1 over the net, with a window configuration such that the remote disk server had to make notification windows, I eventually got up to a window whose label was "Notification: notification: ... notification: foo. Besides this being absurd when I clicked "Select" this label was too wide for the screen and didn't truncate correctly, getting one character onto the next line. Part of the problem is the remote disk server's message is too long and makes **more**'s in the notification window; I will fix that.  Date: 15 JUL 1980 0203-EDT From: MOON at MIT-AI (David A. Moon) To: ACW at MIT-AI CC: (BUG NWS) at MIT-AI Please update the documentation for the following changes which will appear in system 31. New command: esc A arrests the process currently being displayed in the wholine. This is useful when it is making the machine too slow to use the mouse effectively. esc - A revokes all arrest reasons for the process currently being displayed in the wholine; those put on by esc A, those put on by hitting call, and any others that may exist. Changed commands: esc S has been changed around. The most noticeable changes are that esc S and esc 1 S have been interchanged, and that the esc -2 S crock is gone. Also it is now compatible with com-move-to-previous-point and com-select-previous-buffer in the editor (not yet installed on keys in the default environment). esc 0 S remains unchanged. The basic idea is that the numeric argument is the number of previously-selected windows (including the current one) to be "rotated", and it defaults to 2. The least recently selected window in that set rotates to the top and the others are pushed down. A negative argument rotates the other way. An argument of 1 or -1 rotates the other way. This is phrased a couple other ways in the comments in the code (KBD-SWITCH-WINDOWS in BASSTR) and in the self-documentation. The system command has been changed around (I think it now works the way you originally documented it.) [We may change it again if this way proves to be too much of a crock.] There are two cases: 1, the currently selected window is not of the type you are asking for. You get the most recently selected window of that type, or if there are none it creates one if it can. The currently selected window becomes the most recently selected, so esc S will return to it (and esc S again will undo that). 2, the currently selected window is of the type you are asking for. If there are any more, it will make the current window LEAST recently selected (use esc - S to return to it) thus rotating through all windows of that type if you repeat it. If there aren't any more it will beep, it won't make more, the theory being that you probably spazzed rather than really wanted another. Maybe we'll put in hair with numeric arguments for the system key, or maybe we'll control ourselves.  Date: 14 JUL 1980 1841-EDT From: MMcM at MIT-AI (Mike McMahon) Subject: statistics To: (BUG NWS) at MIT-AI, (BUG ZWEI) at MIT-AI ZMAIL uses 92. different windows, of a total of 30. different flavors, constructed with 121. total base flavors and mixins, out of the system total of 233. different flavors.  Date: 14 JUL 1980 1839-EDT From: MMcM at MIT-AI (Mike McMahon) To: (BUG NWS) at MIT-AI Selection still does not work with frames. If one pane of a frame is selected, and you wish to temporarily select another one, you cannot accomplish this as you would with an ordinary window by sending a :STATUS, then a :SELECT, do whatever you want and then a :SET-STATUS to restore things, because the :SET-STATUS will deselect the entire frame, rather than reselecting the other pane.  Date: 14 JUL 1980 1304-EDT From: MMcM at MIT-AI (Mike McMahon) Sent-by: NLM at MIT-AI To: (BUG NWS) at MIT-AI In the version of NWS on system 30.3, with microcode 671, on LISP Machine Two: CC still uses CONSOLE-IO-PC-PPR, so debugging cannot be done in this system.  Date: 14 JUL 1980 1302-EDT From: MMcM at MIT-AI (Mike McMahon) Sent-by: NLM at MIT-AI To: (BUG NWS) at MIT-AI CC: HES at MIT-AI I put a (or mouse-reconsider) in the Usurped clause of MOUSE-OVERSEER, since that appears to get set randomly in places before WITH-MOUSE-GRABBED-INTERNAL can notice that it was NIL for a while. This unfortunately will cause an occasional MOUSE-SET-BLINKER-CURSORPOS, which might be undesirable; it should be fixed in a more satisfactory manner.  Date: 14 JUL 1980 0427-EDT From: Moon at MIT-AI (David A. Moon) Subject: Terminal Clear-Input To: (BUG NWS) at MIT-AI It clears the general io buffer but not the selected window's specific i/o buffer, thus it does not clear typeahead typed before a window-switch. On the other hand this prevents it from clearing special signals sent in via :force-kbd-input. What to do?  Date: 14 JUL 1980 0029-EDT From: Moon at MIT-AI (David A. Moon) Subject: Gratuitous changes To: (BUG NWS) at MIT-AI As long as I was changing most of the files anyway, I put in copyrights and renamed RESOURCE to WITH-RESOURCE.  Date: 14 JUL 1980 0003-EDT From: Moon at MIT-AI (David A. Moon) To: (BUG NWS) at MIT-AI I have made the changes discussed earlier to end-of-line handling. I also took the opportunity to rewrite sheet-string-out, sheet-line-out, and sheet-compute-motion to some extent. These changes seem to have fixed the complaints I had about continuation lines earlier. I think they also make SHEET-RIGHT-MARGIN-CHARACTER-FLAG work more. Judging by some kludgey code in SHEET-LINE-OUT I flushed, there may be some crocks in editor redisplay that can be flushed now. It is no longer the case the SHEET-LINE-OUT can sometimes smash the line after the one you were outputting to. I'll try and dump out a new world before I go.  Date: 13 July 1980 16:55-EDT From: Howard I. Cannon Subject: end-of-line-exception with variable width (e.g. italic) fonts To: MOON at MIT-MC cc: BUG-NWS at MIT-MC Your suggested change sounds good to me. I guess the end-of-line handlers in SCROLL and TSCROL should be looked at to make sure that they won't break.  Date: 13 July 1980 16:36-EDT From: Mike McMahon Subject: terminal clear-input is broken To: MOON at MIT-MC cc: BUG-NWS at MIT-AI MOON@MIT-MC 07/12/80 20:36:57 Re: terminal clear-input is broken, says MMcM Typing at a lisp listener (in 30.3) (process-sleep 300.) foo terminal clear-input works. In what circumstances is it broken? Well, i had a frame the whole size of the screen and the who-line said TYI, but the window was not receiving input, so i entered the cold load stream to see what TV:SELECTED-WINDOW was, when it was indeed the frame, i $P'ed, and typed FORM at the frame a few times. I then guesed it might be in TYI in some other window, so i typed ABORT, and it started getting the FORM's. Because of paging, refreshing the frame takes about 15 seconds (each time, it doesn't get better), so i had to sit there for several minutes waiting for it to stop, and TERMINAL CLEAR-INPUT did not help. I guess i can try to narrow it down next time i have a machine.  MOON@MIT-MC 07/13/80 16:33:38 Re: end-of-line-exception with variable width (e.g. italic) fonts To: (BUG NWS) at MIT-MC Probably we should change end of line exception all around. There should be no flag bit for it, and it should not be handled by prepare-sheet. Instead each thing that outputs characters should check before each character if there is room; if not, funcall-self ':end-line-exception then start over. Things that don't output characters shouldn't care whether the cursor is near the end of the line. Does this sound reasonable? This means that the sheet is already prepared when end-line-exception is signalled, will that break anything? There's a flag in the sheet somewhere that all these guys should look at to decide where the right limit is (whether to leave room for an "!" or not); also the guy who prints the "!" for a continuation line, who probably belongs inside the :end-line-exception handler, has to ignore said flag. Also sheet-display-centered-string and friends should never signal end line exception, they should simply truncate if the sheet is not wide enough for the string they are asked to display.  MOON@MIT-MC 07/12/80 20:36:57 Re: terminal clear-input is broken, says MMcM To: (BUG nws) at MIT-AI Typing at a lisp listener (in 30.3) (process-sleep 300.) foo terminal clear-input works. In what circumstances is it broken?  Date: 12 JUL 1980 1958-EDT From: MMCM at MIT-AI (Mike McMahon) To: (BUG NWS) at MIT-AI the special pdl of the mouse process is not large enough for four levels of hierarchy, now that the :mouse-standard-blinker is called from within the :handle-mouse.  Date: 12 JUL 1980 1916-EDT From: MMcM at MIT-AI (Mike McMahon) To: (BUG NWS) at MIT-AI Something should be done about the kludge needed for italic fonts in MENU-ITEM-STRING-WIDTH, perhaps it should be done by SHEET-STRING-LENGTH, or the right data should be in the font itself. A similar kludge had to be put into SHEET-DISPLAY-CENTERED-STRING to make variable width font menus work. Something definitely needs to be done about this. Perhaps SHEET-STRING-OUT should be smarter when it knows what the next character is.  Date: 12 JUL 1980 1753-EDT From: MMcM at MIT-AI (Mike McMahon) To: (BUG NWS) at MIT-AI Something should be done about the kludge needed for italic fonts in MENU-ITEM-STRING-WIDTH, perhaps it should be done by SHEET-STRING-LENGTH, or the right data should be in the font itself.  Date: 12 JUL 1980 1735-EDT From: MMcM at MIT-AI (Mike McMahon) To: (BUG NWS) at MIT-AI GRIND needs to be recompiled in a world where UNTYO-MARK and UNTYO are not global. grinding currently does not work in the editor in system 30.  Date: 12 JUL 1980 1734-EDT From: MMcM at MIT-AI (Mike McMahon) To: (BUG NWS) at MIT-AI [TERMINAL] [CLEAR-INPUT] appears to be broken.  Date: 12 July 1980 13:18-EDT From: Howard I. Cannon To: Moon at MIT-AI cc: BUG-NWS at MIT-AI Oh yeah, the color screen, I forgot to mention.... My suggested fix is to have DISK-SAVE deexposed everything on ALL-THE-SCREENS list. The color screen won't expose itself unless there is a color monitor on the machine. How about that?  Date: 12 JUL 1980 0236-EDT From: Moon at MIT-AI (David A. Moon) To: (BUG NWS) at MIT-AI In the version of NWS on system 30.3, with microcode 671, on LISP Machine Six: As you can see it is installed on CADR-6. There is a bug by which it tried to screen manage the color screen before it noticed that it didn't have any color hardware and took it off the ALL-THE-SCREENS list, thus the system would not boot without a color TV. This is fixed in the source (TV:INITIALIZE) but not stuck into any worlds, except that I binarily patched the LOD2 partition on CADR-6. Before making any more worlds we should fix this in a more permanent way.  Date: 12 JUL 1980 0022-EDT From: Moon at MIT-AI (David A. Moon) To: (BUG NWS) at MIT-AI In the version of NWS on system 30.2, with microcode 671, on LISP Machine One: In PEEK, clicking the left button on a mouse-sensitive item gives you a menu. In all other nws displays that I know of this function is on the right button, which seems to be unused in PEEK.  Date: 11 July 1980 19:50-EDT From: Howard I. Cannon To: ACW at MIT-AI cc: BUG-NWS at MIT-AI The reason for :BITBLT's arg order is that it is parrallel to BITBLT, which many people are already familier with. I see no reason to change it.  Date: 11 JUL 1980 1944-EDT From: ACW at MIT-AI (Allan C. Wechsler) To: (BUG NWS) at MIT-AI In the version of NWS on system 29.95 NWS, with microcode 669, on LISP Machine Eleven: Could someone give me a capsule lecture on exactly what the microcode drawing primitives are? I have a feeling we could do a lot of clipping in microcode and a) speed things up a lot, and b) eliminating weird min/max clipping code from the window system proper. Meseemeth that a window system needs good clipping support and that the methods shouldn't have to worry about it too much. ---Wechsler  Date: 11 JUL 1980 1939-EDT From: ACW at MIT-AI (Allan C. Wechsler) To: (BUG NWS) at MIT-AI In the version of NWS on system 29.95 NWS, with microcode 669, on LISP Machine Eleven: Unless there are ancient historical reasons for doing it this way, I find the names and argument orders for the :BITBLT and :BITBLT-FROM-SHEET messages a little clumsy. At present: :BITBLT ALU WID HEI FROM-ARRAY FROM-X FROM-Y TO-X TO-Y :BITBLT-FROM-SHEET ALU WID HEI FROM-X FROM-Y TO-ARRAY TO-X TO-Y I would suggest: :BITBLT-FROM ARRAY ALU WID HEI FROM-X FROM-Y TO-X TO-Y :BITBLT-TO ARRAY ALU WID HEI FROM-X FROM-Y TO-X TO-Y respectively. I could give all the reasons for this but I fear I have flamed excessively already. ---Wechsler  Date: 11 JUL 1980 1755-EDT From: ACW at MIT-AI (Allan C. Wechsler) To: (BUG NWS) at MIT-AI In the version of NWS on system 29.95 NWS, with microcode 669, on LISP Machine Eleven: Forms like (ARRAY-LEADER RUBOUT-HANDLER-BUFFER 1) are confusing. Perhaps these could be replaced by something more evocative? I have not been able to figure out what these are for. Perhaps a DEFSTRUCT would be better. ---Wechsler  MOON@MIT-MC (Sent by MOON5@MIT-MC) 07/11/80 16:52:51 To: (BUG NWS) at MIT-MC Date: 11 July 1980 10:16-EDT From: Howard I. Cannon Subject: Screen editor not working in new system To: Moon at MIT-AI cc: BUG-NWS at MIT-AI The only problem is that MMCM and I fixed the screen editor lossage two days ago!! What problem were you fixing -- the one that MMCM reported? I guess I'll look into it losing, but I'm completely baffled by your bug report. You can't possibly have fixed it two days ago. I loaded your qfasl files and they had no effect on the symptoms, so I looked at the code and determined that it couldn't possibly work, as in my mail sent this morning. We should get our act together tonight.  Date: 11 July 1980 10:16-EDT From: Howard I. Cannon Subject: Screen editor not working in new system To: Moon at MIT-AI cc: BUG-NWS at MIT-AI The only problem is that MMCM and I fixed the screen editor lossage two days ago!! What problem were you fixing -- the one that MMCM reported? I guess I'll look into it losing, but I'm completely baffled by your bug report.  Date: 11 JUL 1980 0651-EDT From: Moon at MIT-AI (David A. Moon) Subject: Screen editor not working in new system To: (BUG NWS) at MIT-AI This was because the WITH-MOUSE-GRABBED macro did not work, and because the SCRED had never been converted to the new way of doing the mouse blinker (MOUSE-SET-BLINKER and friends.) I did a lot of work on fixing this, but there are still problems where both the mouse process and the screen-editing process are trying to set the mouse blinker at the same time which I am now too burned-out to figure out. I did not dump out a new world nor make qfasl files with these fixes, they are only in the source. Current state if those sources are compiled into 30.2 is that everything works except that move-multiple leaves turds of the multiple rectangle blinker, and occasionally it blows out in find-edge-or-corner because the mouse process has changed the blinker back to a character. It's probably something obviously wrong that I'm just too tired to see. Except for the screen editor 30.2 seems to be pretty reliable.  Date: 11 JUL 1980 0303-EDT From: MOON5 at MIT-AI (David A. Moon) To: (BUG NWS) at MIT-AI I think MOUSE-OVERSEER now has a timing bug with respect to WITH-MOUSE-GRABBED in that it setq MOUSE-WINDOW -before- it calls MOUSE-STANDARD-BLINKER.  Date: 11 JUL 1980 0206-EDT From: Moon at MIT-AI (David A. Moon) To: (BUG NWS) at MIT-AI Are the bunch of OR BOUNDP's at the end of TV:INITIALIZE still utile? TVDEFS is loaded well before SHWARM.  Date: 11 JUL 1980 0156-EDT From: MOON5 at MIT-AI (David A. Moon) To: (BUG NWS) at MIT-AI The reason there was so much lossage with packages in this new world was a bug with REMOB or INTERN, not updating the package cell of a symbol when it is manually moved from one package to another. I will fix that and build a 30.2 world on CADR-1 before I go home tonight. I may or may not get a chance to move it to CADR-6. Note: if you change it on one machine please make the same changes on the other machine too.  Date: 10 JUL 1980 2201-EDT From: Moon at MIT-AI (David A. Moon) To: (BUG NWS) at MIT-AI I have removed another goddamn (funcall window ':expose nil ':clean), this time in the split screen operation of the system menu. Was it there for a reason?  Date: 10 JUL 1980 1531-EDT From: MMcM at MIT-AI (Mike McMahon) To: (BUG NWS) at MIT-AI CONSTRAINT-FRAME-RECOMPUTE-CONFIGURATION deexposes all panes, then sets their edges, and reexposes them; so, panes whose edges do not change and which do not have bit arrays get refreshed anyway. That function also does all this with the frame deexposed, the aesthetics of which i agree with, but which may slow things down a fair amount, and serves to hide the excess refreshing going on.  MOON@MIT-MC 07/10/80 05:00:24 Re: Your bug To: FAIL at MIT-AI CC: (BUG NWS) at MIT-MC The system does not yet make any reasonable attempt to deal with stack overflows. This is something I intend to work on soon. Also the default special-pdl size was chosen long ago and is now much too small; it will be changed. You can alleviate the symptom for now by using the ':special-pdl-size option to process-create with an argument of 2000 or so.  MOON@MIT-MC 07/10/80 04:44:32 To: (BUG NWS) at MIT-MC LMWIN@MIT-AI 07/10/80 01:11:33 To: (BUG NWS) at MIT-AI TV should borrow SI:KBD-LEFT-SHIFTS and SI:KBD-RIGHT-SHIFTS or there should be an advertised interface to these or their IOR. It presumably has to be an interface function since the keyboard is not looked at very often if no one is reading from it. Presumably the appropriate interface is really something which, given the name of a key, tells you whether that key is currently depressed.  LMWIN@MIT-AI 07/10/80 01:11:33 To: (BUG NWS) at MIT-AI TV should borrow SI:KBD-LEFT-SHIFTS and SI:KBD-RIGHT-SHIFTS or there should be an advertised interface to these or their IOR.  MMCM@MIT-AI 07/09/80 22:14:54 Re: bugs in 30.1 To: (BUG NWS) at MIT-AI Move multiple does not work because something keeps changing the mouse blinker back to a character blinker from the large arrow. The inspector does not work because it was compiled in a world where FORCE-KBD-INPUT was globalized.  FAIL@MIT-AI 07/09/80 20:57:45 Re: how to reproduce the bug To: (BUG NWS) at MIT-AI In system 29.95 NWS, with microcode 663, on LISP Machine Three: (Setq eh:error-handler-io tv:cold-load-stream) revealed that the problem mainfests itself as a special pdl overflow in attempting to print error messages, etc. Actually, there seem to be several bugs with this same manifestation, not just one. The simplest way I have got to produce one is (setq broken-process (process-create 'break)) (defflavor broken-window nil (tv:process-mixin tv:window)) (setq broken-window (tv:window-create 'broken-window ':process broken-process)) (defun break-up nil (print (eval (read)))) (defun break-it nil (process-preset broken-process ' break-up) (<- broken-window 'select)) (break-it) (setq foo 2) Now it may be that there are bugs in the above code that are causing the probelm, but the tight RUN loop is still not a good thing. If break-it setqs terminal-io to broken-window, a different bug will manifest itself with the same symptom.  Date: 9 July 1980 14:28-EDT From: Howard I. Cannon To: BUG-NWS at MIT-MC MSG: WINDOW 1 Date: 07/09/80 12:27:54 From: Gordon Oro at MIT-AI Re: Window Washing It is that time again! Windows are being washed! Please clean your window area of plants, books, etc. and grant access to the window washers so they may clean the window(s) in your room(s).  MOON@MIT-AI (Sent by MOON0@MIT-AI) 07/09/80 08:50:28 To: (BUG NWS) at MIT-AI I left a band transfer to cadr-6 going, I don't know if it will complete. Note that it's set up to use a microcode that isn't on cadr6 yet (671)  MOON@MIT-AI (Sent by MOON0@MIT-AI) 07/09/80 08:48:16 To: (BUG NWS) at MIT-AI 30.1 fixes the GLOBAL:MOUSE lossages aforementioned, at least all that I could find.  Moon@MIT-AI 07/09/80 07:56:16 To: (BUG NWS) at MIT-AI The system 30.0 band is 10356. blocks long.  Moon@MIT-AI 07/09/80 07:53:39 To: (BUG NWS) at MIT-AI Things broken in 30.0. Well, I found out why MOUSE was getting globalized. In the old system it was shadowed by TV, and global in the system, so :MOUSE became GLOBAL:MOUSE and explicit instructions to put this in GLOBAL were put in the qfasl file. I forgot to move it back from GLOBAL to USER before I recompiled everything. So everything that managed to find GLOBAL:MOUSE needs to be recompiled, with GLOBAL:MOUSE REMOBed. This includes at least CHOICE and SYSMEN. (This is why, for example, the multiple choose window the editor uses to save files appears in the wrong place.) Sigh. I guess I will work on this tomorrow.  Moon@MIT-AI 07/09/80 07:35:54 To: (BUG NWS) at MIT-AI System 30 exists on MCR2 and LOD3 of CADR-1. It has not been very thoroughly tested. NOTE: the standalone mail/bug commands are still broken with STANDARD-INPUT undefined instance variable.  Date: 8 July 1980 12:25-EDT From: Mike McMahon To: ZVONA at MIT-AI cc: BUG-NWS at MIT-AI Zvona@MIT-AI 07/05/80 21:53:11 in a situation where i have a window with its own process which tries to format onto the (wholly unexposed) lisp-listener from which it was called, the machine hesitates and then goes into a tight RUN loop from which it must be warm booted. This is quite reproducible if you want to see it. Why don't you tell us how to reproduce it, or find one of us next time you do. You might also try setting EH:ERROR-HANDLER-IO to TV:COLD-LOAD-STREAM first, since a half-broken TERMINAL-IO might be causing problems.  Date: 8 July 1980 12:08-EDT From: Mike McMahon To: MOON at MIT-AI cc: BUG-NWS at MIT-AI MOON@MIT-AI (Sent by MOON0@MIT-AI) 07/08/80 05:16:57 It sucks totally that the cold load stream inhibits interrupts while waiting for keyboard input, since if it asks you a question while loading the world the Chaosnet connection goes away. Let's fix this! If a runaway process is trying to read from the keyboard, it will gobble most of your input, and the cold load stream won't be able to save your ass.  MOON@MIT-AI (Sent by MOON0@MIT-AI) 07/08/80 05:16:57 To: (BUG NWS) at MIT-AI It sucks totally that the cold load stream inhibits interrupts while waiting for keyboard input, since if it asks you a question while loading the world the Chaosnet connection goes away. Let's fix this!  MMCM@MIT-AI 07/07/80 22:28:05 To: (BUG NWS) at MIT-AI the :set-item-list message for menus seems a bit too eager to recompute the geometry. probably, if the item list is EQUAL to the old one, just SETQ'ing it and the other appropriate variables would work. more importantly, if the menu is part of a deexposed frame with a bit-save array, and the frame is not large enough to hold the new menu with the standard geometry, you get an error; the next thing my code does is compute the right size for the frame anyway, so i'd just as soon there were a way to skip this step.  MOON@MIT-AI 07/06/80 00:52:11 To: (BUG NWS) at MIT-AI The file AI: MOON; SYS30 MSG is a message to be sent out to INFO-LISPM with the installation of system 30 (which hasn't been built yet, but I'm working on it.) Please fix up anything therein that needs it.  MOON5@MIT-AI 07/05/80 22:49:16 To: (BUG NWS) at MIT-AI In 29.100 nws, restoring a screen layout via "Layouts" in the system menu refreshes all the windows involved in the layout, even though they had bit save arrays and should have been able to restore their bits. This was caused by explicit code giving :CLEAN to the :EXPOSE message. I took it out, because it was obviously wrong, but I wonder why it was there. Also, I have changed the format of a saved layout to remember the selected window so it won't select a window at random. On a different topic, the :mouse-select operation's function of saving typeahead in the selected window's I/O buffer should be modularized out and called very much earlier by operations like window creation that run and page for a long time then do a :mouse-select. Otherwise characters typed long after the mouse operation get saved as typeahead to the wrong window.  Zvona@MIT-AI 07/05/80 21:53:11 To: (BUG NWS) at MIT-AI In system 29.96 NWS, with microcode 669, on LISP Machine Two: in a situation where i have a window with its own process which tries to format onto the (wholly unexposed) lisp-listener from which it was called, the machine hesitates and then goes into a tight RUN loop from which it must be warm booted. This is quite reproducible if you want to see it.  MMcM@MIT-AI 07/05/80 21:21:42 To: (BUG NWS) at MIT-AI I have significantly cleaned up the time-related routines in LMIO;CHSAUX, added some new ones, including a date/time parser, and moved the whole lot into LMIO1;TIME. I made a new package for it, so all the things that knew about CHAOS:NWATCH-ON, CHAOS:WHAT-TIME, CHAOS:WHAT-DATE, etc. will need to be changed. I have updated PKGDCL and LFL also. All this should be taken into account in building this new system.  TAFT@MIT-AI 07/05/80 09:37:00 To: (BUG NWS) at MIT-AI Why does this work: (TV:SOFTWARE-CREATE ':NWS ':WONDERFUL-THING-P T ':DOCUMENTATION-P NIL ':CONSTRAINTS ':ARCANE-TURDS!)  Moon@MIT-AI 07/03/80 01:11:19 Re: Progress toward an NWS-only cold-load To: (BUG NWS) at MIT-AI I have obviated the remaining things in WINTST, gotten rid of JOBDEF and KBD, and fixed up LISPM2;PROCES and COLD. The following remain to be done: PKGDCL, GLOBAL, PACK4, LFL QLD (in LFL) needs a lot of work. We are going to have to figure out how things are going to load. Currently it wants to set up windows and the error handler before setting up processes. Windows undoubtedly need processes to load. We don't really need windows except without them loaded we can't load other things, including the error handler. We will have to work on this. Also note that we cannot load anything that uses flavors in it before loading the compiler. I have moved LMWIN;LTOP back to LISPM;.  Date: 2 July 1980 23:55-EDT From: Mike McMahon To: BAK at MIT-AI cc: BUG-NWS at MIT-AI BAK@MIT-AI 07/02/80 23:32:27 Named structures that know how to print themselves do not function correctly in the inspector. When a list of these structures was inspected it displayed some white space instead of the appropriate string. The :print message handler was: (defun viewpoint (operation viewpoint &rest parameters) (cond ((eq operation ':which-operations) '(:print)) ((eq operation ':print) (princ (string-downcase (viewpoint-symbol viewpoint)))))) The second argument to the :PRINT message for named structures is the stream to print to. You want (defun viewpoint (operation viewpoint &rest parameters) (cond ((eq operation ':which-operations) '(:print)) ((eq operation ':print) (princ (string-downcase (viewpoint-symbol viewpoint)) (car parameters))))) or something like that. I imagine if you looked closely when using the inspector, the object got printed to some random window.  BAK@MIT-AI 07/02/80 23:32:27 To: (BUG NWS) at MIT-AI CADR3, system 29.95: Named structures that know how to print themselves do not function correctly in the inspector. When a list of these structures was inspected it displayed some white space instead of the appropriate string. The :print message handler was: (defun viewpoint (operation viewpoint &rest parameters) (cond ((eq operation ':which-operations) '(:print)) ((eq operation ':print) (princ (string-downcase (viewpoint-symbol viewpoint))))))  Moon@MIT-AI 07/02/80 20:40:13 To: (BUG NWS) at MIT-AI I moved some stuff from BASSTR to LISPM2;PROCES that logically was in WINTST.  Date: 2 July 1980 02:05-EDT From: Howard I. Cannon To: BAK at MIT-AI cc: BUG-NWS at MIT-AI You should not be doing sheet-set-cursorpos directly. You should be sending the :set-cursorpos message, which functions in terms of inside coordinates (excluding the margins, that is). This is the coordinate system in which the user wants to work.  BAK@MIT-AI 07/01/80 23:02:35 To: (BUG NWS) at MIT-AI I created an unadorned window (with the :blinker-p option nil) and tried executing: (tv:sheet-set-cursorpos the-score x y). It did not place the cursor at the correct position. For positions near the top of the screen it set the cursorpos to approx y=100 pixels down from the top. For other positions the cursorpos seemed to go a few pixels greater in both the x and y direction. I changed the code to: (setf (tv:sheet-cursor-x the-score) x) (setf (tv:sheet-cursor-y the-score) y) and it functioned correctly. tv:sheet-set-cursorpos is apparently trying to do something clever that it shouldn't.  Date: 1 July 1980 22:57-EDT From: Mike McMahon Sender: MMcM at CADR6 at MIT-AI To: BUG-NWS at MIT-AI a lot of stuff has been moved out of WINTST into the appropriate system files. if you have occasion to build a new system without those latter, you should use the OQFASL for WINTST. if you need to modify any of the functions involved, you should be careful.  MMCM@MIT-AI 07/01/80 20:20:26 Re: rampant vandalism To: (BUG NWS) at MIT-AI pop-up-qsend is amazingly bad off. the notification may be less interruptive, although i took a while to notice it among a lot of other random text. but, once found, there is no convenient way to select that window explicitly, like [system] q. and finally, selecting that window brings up no bits, moves the cursor to someplace weird and says flushed in the who line, all of which contributed to my not getting the message at all in the end, except via print-sends.  rg@MIT-AI 07/01/80 16:37:00 To: (BUG NWS) at MIT-AI I installed a kludge that allows you to simulate mouse buttons from the keyboard. There is a variable KBD-BUTTONS, which gets set up by KBD-ENCODE-NEW, and gets IORed with the real mouse buttons by MOUSE-BUTTONS and MOUSE-INPUT. Roman numerals I, II, and III are the left, middle and right buttons. This is mainly to let you play with Purbrick's keyboard thumb-joystick which is installed on cadr7.  Moon@MIT-AI 07/01/80 00:58:03 Re: LMWIN; dir full To: (BUG NWS) at MIT-AI, ACW at MIT-AI I contributed to this by adding a new file, CHOICE, and detracted from it by moving some remaining documentation files onto LMWIND;  Moon@MIT-AI 06/30/80 23:55:44 To: (BUG NWS) at MIT-AI The error handler completely ignores the stream ERROR-OUTPUT, and uses TERMINAL-IO. Should we change this?  Date: 30 June 1980 22:58-EDT From: Mike McMahon To: BAK at MIT-AI cc: BUG-ZWEI at MIT-AI, BUG-NWS at MIT-AI Date: 29 JUN 1980 0246-EDT From: BAK at MIT-AI (William A. Kornfeld) System 29.95. When doing a meta-. from the editor I get the error message from within the function FILE-SPREAD-PATHNAME " not an acceptable pathname". It does not always happen, but once it starts (I'm not sure what the catalyst is) it continues doing this. I'm using multi-font files at the time so this be causing it some confusion. This bug was never noticed under the old window system. I fixed the bug where things put into the kill ring from a file with fonts and unkillt in the mini-buffer would cause this screwup.  Moon@MIT-AI 06/30/80 20:37:42 Re: p.s. TO PREVIOUS To: (BUG NWS) at MIT-AI i HAVE FIXED THE INSPECTOR NOT TO DO THE WRONG THING WITH INSPECTING FLAVORS. i STILL DON'T KNOW WHO'S PUTTING ON THAT PROPERTY AND WHY.  Date: 30 June 1980 20:31-EDT From: Mike McMahon To: MOON at MIT-AI cc: BUG-NWS at MIT-AI Moon@MIT-AI 06/30/80 20:24:56 Inspecting tv:cold-load-stream gets an error because someone (i haven't found the culprit yet) puts a bogus si:flavor property on that symbol. Why is this being done? (The value of the property is t) To make M-.'ing its methods work, i told you about this last time.  Moon@MIT-AI 06/30/80 20:24:56 To: (BUG NWS) at MIT-AI In the version of nws on system 29.99 nws, with microcode 669, on LISP Machine Six: iNSPECTING TV:COLD-LOAD-STREAM GETS AN ERROR BECAUSE SOMEONE (I HAVEN'T FOUND THE CULPRIT YET) PUTS A BOGUS SI:FLAVOR PROPERTY ON THAT SYMBOL. WHY IS THIS BEING DONE? (THE VALUE OF THE PROPERTY IS T) ALSO, AS YOU CAN SEE IN THIS WORLD ELECTRIC SHIFT LOCK CAN DO THE WRONG THING IN MAIL MODE. I DON'T KNOW WHY THIS HAPPENED, I SENT THE MAIL OUT OF A LISP MODE BUFFER, AND ALSO HAVE SOME ZTOP AND TEXT MODE BUFFERS.  ZVONA@MIT-AI 06/30/80 03:28:10 To: (BUG NWS) at MIT-AI The qsend pop-up window should use yes-or-no-p, not y-or-n-p for Reply? I get screwed by this all the time; if you are typing without watching you can either lose the qsend altogether or get into reply where you didn't want to. (Incidentally, there seems to be no way to abort a reply, or at least it is not documented. Abort would be consistent with End, or c-] with c-, or c-z with c-c...)  MOON@MIT-MC 06/29/80 21:31:31 Re: esc n S To: (BUG NWS) at MIT-MC esc S and COM-SELECT-PREVIOUS-BUFFER / COM-MOVE-TO-PREVIOUS-POINT have a discrepancy in how they treat their numeric argument. I think we should change esc S as follows: esc S rotates the whole ring backwards esc - S rotates the whole ring forwards esc 0 S finds an error window esc n S rotates the first n on the ring backwards esc -n S rotates the first n on the ring forwards The current functionality of esc -2 S is discarded. Note that esc 1 S and esc -1 S are noops and could do something different if we wanted. This is consistent with the editor. Unless someone barfs I will do this and at the same time change SYSTEM to do something reasonable, including treating a numeric arg the same way except only rotating through windows of the same type. Somehow I will make SYSTEM undoable with esc S rather than esc - S as it is now.  Date: 29 June 1980 12:37-EDT From: Mike McMahon To: BAK at MIT-AI cc: BUG-ZWEI at MIT-AI, BUG-NWS at MIT-AI Date: 29 JUN 1980 0246-EDT From: BAK at MIT-AI (William A. Kornfeld) System 29.95. When doing a meta-. from the editor I get the error message from within the function FILE-SPREAD-PATHNAME " not an acceptable pathname". It does not always happen, but once it starts (I'm not sure what the catalyst is) it continues doing this. I'm using multi-font files at the time so this be causing it some confusion. This bug was never noticed under the old window system. Do you move text into the mini-buffer from the main window?  Date: 29 JUN 1980 0309-EDT From: BAK at MIT-AI (William A. Kornfeld) Subject: Correction to previous bug msg. To: (BUG ZWEI) at MIT-AI, (BUG NWS) at MIT-AI The error attributed to meta-. actually happened with ctrl-X ctrl-F.  Date: 29 JUN 1980 0246-EDT From: BAK at MIT-AI (William A. Kornfeld) To: (BUG ZWEI) at MIT-AI, (BUG NWS) at MIT-AI System 29.95. When doing a meta-. from the editor I get the error message from within the function FILE-SPREAD-PATHNAME " not an acceptable pathname". It does not always happen, but once it starts (I'm not sure what the catalyst is) it continues doing this. I'm using multi-font files at the time so this be causing it some confusion. This bug was never noticed under the old window system.  Date: 28 June 1980 19:22-EDT From: Mike McMahon To: MOON at MIT-MC cc: BUG-NWS at MIT-AI MOON@MIT-MC 06/28/80 17:18:21 esc S and COM-SELECT-PREVIOUS-BUFFER / COM-MOVE-TO-PREVIOUS-POINT have a discrepancy in how they treat their numeric argument. esc 2 S cycles among 3 windows while in the editor this would cycle between 2 places. It's important that we resolve this; I don't have a proposal yet for what is the right thing. The editor's interpretation is based on the H command in ETV, for what that is worth.  MOON@MIT-MC 06/28/80 17:18:21 To: (BUG NWS) at MIT-MC esc S and COM-SELECT-PREVIOUS-BUFFER / COM-MOVE-TO-PREVIOUS-POINT have a discrepancy in how they treat their numeric argument. esc 2 S cycles among 3 windows while in the editor this would cycle between 2 places. It's important that we resolve this; I don't have a proposal yet for what is the right thing.  MOON@MIT-MC 06/28/80 16:57:37 To: JERRYB at MIT-AI CC: HENRY at MIT-MC, (BUG NWS) at MIT-MC Date: 28 June 1980 13:50-EDT From: Gerald R. Barber To: HENRY at MIT-AI cc: BUG-NWS at MIT-AI Date: 06/27/80 03:00:54 From: HENRY at MIT-AI To: (BUG NWS) In system 29.95 NWS, with microcode 669, on LISP Machine Eight: Using the string "CALL a function" in a menu with font PRT12B causes the n at the end of function to wrap around to the next line. I had a lot of trouble with this too, it is because you are using a variable width font. In the old window system there was a variable called pc-ppr-right-limit that is left of the right margin by the width of the widest character. If any output is tryed to the right of this limit a carriage return is forced. The code that calculates what size the pc-ppr should be doesn't take this into account. It looks like the new window system has the same problem. Actually the bug had nothing to do with that. It's fixed in the source.  Date: 28 June 1980 16:06-EDT From: Howard I. Cannon To: MOON at MIT-MC cc: BUG-NWS at MIT-MC What I might like is a kind of method combination that has an additional thing: (defmethod (foo :predicate :activate) (&rest args) (some-predicate-p args)) which expands into something like: (cond ((and (apply #'foo-predicate-activate-method args)) ... the standard thing ...)) Wrappers would of course go around. This could be useful for other things as well. If you think is total bullshit, then having wrappers on thise things would be fine.  MOON@MIT-MC 06/28/80 15:56:32 To: (BUG NWS) at MIT-MC MMcM@MIT-AI 06/26/80 15:08:33 To: (BUG NWS) at MIT-AI [SYSTEM] should probably look for activated windows that were never selected before creating a new one, or else there should be an init option akin to :ACTIVATE which puts the window at the end of the previously selected windows. I made a daemon (SELECT-MIXIN :AFTER :ACTIVATE) which adds a window to end of previously-selected-windows. Adding it unconditionally seems to be the right thing, since when it's taken out of there it's checked for whether it's mouse-selectable. It's a real drag that these daemons get called unconditionally when the :ACTIVATE message is sent, regardless of whether the window was already active. What do you think of putting in wrappers for this group of messages that cause nothing to happen if the window is already active? (This is different from the test-under-lock in (SHEET :ACTIVATE) for whether it's already active, necessary to prevent gaffes like putting in twice on the list of inferiors. At the wrapper level a lock wouldn't be needed, since naturally if one guy is trying to activate and another is trying to deactivate at the same time, the final state is unpredictable.  Date: 28 June 1980 15:52-EDT From: Mike McMahon To: MOON at MIT-AI cc: BUG-NWS at MIT-AI Date: 28 JUN 1980 1526-EDT From: Moon at MIT-AI (David A. Moon) In a freshly loaded world, if I first go into the editor via system E rather than (ed), and use meta-. to read in a file and point at a function, then use esc S to leave the editor, then later use (ed), something anomalous happens. It comes up in BUFFER-1 instead of the buffer I was in, and when I reselect that buffer its point is at the beginning instead of where it was. Furthermore when (ED) first stabilizes it leaves the who-line saying RUN instead of TYI (but nothing is running). Clicking the mouse on the BUFFER-1 window fixes the who-line. The problem is that [SYSTEM] E does not find the main editor window since it has never been selected, as mentioned in a bug report of a few days ago. The other problem is that this and [ESC] S are not editor commands and hence do not save the state of the windows like C-Z does, but rather act as if the mouse had been used.  MOON@MIT-MC 06/28/80 15:31:22 To: (BUG NWS) at MIT-MC CC: HENRY at MIT-AI HENRY@MIT-AI 06/27/80 03:00:54 To: (BUG NWS) at MIT-AI In system 29.95 NWS, with microcode 669, on LISP Machine Eight: Using the string "CALL a function" in a menu with font PRT12B causes the n at the end of function to wrap around to the next line. Fixed in the source (SHEET-STRING-LENGTH schizophrenic)  Date: 28 June 1980 13:50-EDT From: Gerald R. Barber To: HENRY at MIT-AI cc: BUG-NWS at MIT-AI Date: 06/27/80 03:00:54 From: HENRY at MIT-AI To: (BUG NWS) In system 29.95 NWS, with microcode 669, on LISP Machine Eight: Using the string "CALL a function" in a menu with font PRT12B causes the n at the end of function to wrap around to the next line. I had a lot of trouble with this too, it is because you are using a variable width font. In the old window system there was a variable called pc-ppr-right-limit that is left of the right margin by the width of the widest character. If any output is tryed to the right of this limit a carriage return is forced. The code that calculates what size the pc-ppr should be doesn't take this into account. It looks like the new window system has the same problem.  MMCM@MIT-AI 06/27/80 22:59:07 Re: wish list To: (BUG NWS) at MIT-AI there should perhaps be a pipe-like stream, an extension of the io-buffer. i have something that wants to FORMAT things to be handled by a function that knows how to print a file or other input type stream. the stop output key should maybe send a :STOP-OUTPUT message to the selected window, i want some sort asynchronous interrupt other than abort for telling the program to stop printing stuff? constraint frames or a special subset of them should implement the :compute-geometry that ZMAILF is doing manually, that is deduce their minimum size necessary for all panes to fit.  HENRY@MIT-AI 06/27/80 03:00:54 To: (BUG NWS) at MIT-AI In system 29.95 NWS, with microcode 669, on LISP Machine Eight: Using the string "CALL a function" in a menu with font PRT12B causes the n at the end of function to wrap around to the next line.  Date: 26 June 1980 21:44-EDT From: Mike McMahon To: RSG at MIT-AI cc: BUG-NWS at MIT-AI RSG@MIT-AI 06/26/80 19:31:15 I noticed that setting TV:BEEP does not have the same effect as setting TV-BEEP used to, that is, making the function TV:BEEP beep but not flash the screen. Is there a way to prevent screen flashing in the TV: version of things? Values are NIL (nothing), :BEEP for beep only, :FLASH for flash only, and T (the default) for both. Also, is there a TV: version of TV-WHO-LINE-STREAM ? Yes, it is called TV:WHO-LINE-WINDOW, which i assume does not really answer your question. What do you want to do?  RSG@MIT-AI 06/26/80 19:31:15 To: (BUG NWS) at MIT-AI I noticed that setting TV:BEEP does not have the same effect as setting TV-BEEP used to, that is, making the function TV:BEEP beep but not flash the screen. Is there a way to prevent screen flashing in the TV: version of things? (I was using CADR-1, 29.95 NWS, ucode 669.) Also, is there a TV: version of TV-WHO-LINE-STREAM ? Thanks ... RSG  MMcM@MIT-AI 06/26/80 15:08:33 To: (BUG NWS) at MIT-AI [SYSTEM] should probably look for activated windows that were never selected before creating a new one, or else there should be an init option akin to :ACTIVATE which puts the window at the end of the previously selected windows. [SYSTEM] Q or something like that should get you a QSEND window, prompting for sending; this is hard due to the poor way that whole thing is designed.  MOON@MIT-MC 06/25/80 12:24:10 Re: Flashy scrolling To: HIC at MIT-MC CC: (BUG NWS) at MIT-MC Date: 25 June 1980 08:46-EDT From: Howard I. Cannon Subject: Flashy scrolling To: Moon at MIT-AI cc: BUG-NWS at MIT-AI Seems to me a while ago I EXPLICTITLY objected to doing this, as I thought i useful to be able to scroll things even furthuer than the bottom. Oh well. I had forgotten about that. We can easily change the definition of :SCROLL-MORE-BELOW if you really think that is important (except that I already made other things call it). Is it important?  Date: 25 June 1980 08:50-EDT From: Howard I. Cannon To: RSG at MIT-AI cc: BUG-NWS at MIT-AI Date: 24 June 1980 19:46-EDT From: Robert S. Giansiracusa To: BUG-NWS at MIT-AI On CADR-4, ucode 669, system 29.95 NWS Often when typing something and then rubbing out a character or two (when in a lisp listener other than the initial top window) the entire window gets cleared instead of just the character rubbed out. I'd like to see an example of this. Also -- the compiler complains that TV-DRAW-LINE and TV-DRAW-CHAR are obsolete functions. What are the new names for these? You should send the messages :DRAW-LINE and :DRAW-CHAR (neither of which may be implemented in that version of the system). Note that any use of ANY SYMBOL STARTING WITH TV- uses the old window system, and needs to be considered (this includes the ALU's, btw!). I can give you wimple definitions of those two messages if you wish until the system that has them gets installed. The arguments are the same, execept for taking the sheet.  Date: 25 June 1980 08:46-EDT From: Howard I. Cannon Subject: Flashy scrolling To: Moon at MIT-AI cc: BUG-NWS at MIT-AI Seems to me a while ago I EXPLICTITLY objected to doing this, as I thought i useful to be able to scroll things even furthuer than the bottom. Oh well.  Moon@MIT-AI 06/24/80 23:20:19 Re: Gratuitous changes To: (BUG NWS) at MIT-AI I made flashy scrolling not display its arrows if the window was already scrolled as far as it can go in that direction. Then I added new messages :SCROLL-MORE-ABOVE and :SCROLL-MORE-BELOW, which are used by this and which the editor can compute much more efficiently than the general :SCROLL-POSITION.  RSG@MIT-AI 06/24/80 19:46:17 To: (BUG NWS) at MIT-AI On CADR-4, ucode 669, system 29.95 NWS Often when typing something and then rubbing out a character or two (when in a lisp listener other than the initial top window) the entire window gets cleared instead of just the character rubbed out. Also -- the compiler complains that TV-DRAW-LINE and TV-DRAW-CHAR are obsolete functions. What are the new names for these? Tnks ... RSG  Moon@MIT-AI 06/22/80 04:27:25 Re: Featurama #\SYSTEM To: (BUG NWS) at MIT-AI Here are some features we might consider. I'm not sure I'm really in favor of all of these. But if there are no demurrers (including from me after I've slept on them) I'll go ahead and throw them in. Also not all of them can be done at the same time of course. Instead of putting the current window on the end of the previously-selected-windows, like esc-S, it puts it on the front, like clicking with the mouse, but it has its own table of previously-system'ed windows which it uses to cycle through. Thus the rule is, normally find the most recently selected window of the specified type, but if that would find the current window (i.e. if the current window is of the type searching for) then it uses its own table instead. If there are no windows of the desired type, except the current one, create another one rather than being a no-op. (Would this be a screw sometimes?) Take numeric arguments like esc S, and do exactly the same cycling-through and previous-window saving. Same as above, but sys + cycles through while sys finds the most recently used other than the current. (All of this only matters if you have 3 or more of a given type.) control-system creates a new one even if some already exist. meta-system is like that but creates the new one in the upper half of the screen instead of the full screen. control-meta-system creates a new one in the lower half of the screen.  MOON@MIT-MC 06/22/80 03:32:47 Re: Keyboard problem--holding down 2 control keys, releasing one To: JLK at MIT-MC, CPR at MIT-AI, CL at MIT-AI CC: (BUG NWS) at MIT-MC I have fixed this for the Lisp machine in the source (LMWIN;COLD). Evidently the Plasma 11 has the same bug; the routine in the host computer that tracks the shift keys has to keep track of the left and right shifts separately, so that when it is informed that one was lifted up it doesn't think they both were. You may want to copy that code (translating from Lisp to PALX).  MOON@MIT-MC 06/22/80 01:49:28 To: Henry at MIT-AI CC: (BUG NWS) at MIT-MC Henry@MIT-AI 06/22/80 01:07:10 To: (BUG NWS) at MIT-AI In system 29.95 NWS, with microcode 669, on LISP Machine Four: What's the convention about returning EDGES for windows? Lisp Listeners seem to return a LIST of edges when sent a ':EDGES message, whearas ZWEI's windows [from ZWEI:(WINDOW-SHEET *WINDOW*)] return the edges as multiple values. You are clearly getting an old-window-system window somehow and faking yourself out. There is only one method for :EDGES in the nws and it returns 4 values. I really don't care which way you do it, but how 'bout making the conventions consistent? Also, in OWS, there were useful messages RIGHT, LEFT, TOP, BOTTOM which seem to have disappeared. How about reinstating them. Are you sure these are what you want? I suspect you probably want the :SIZE or :INSIDE-SIZE message. Do you really want to know the coordinates of a window's corners relative to its superior?  Moon@MIT-AI 06/22/80 01:41:21 To: (BUG NWS) at MIT-AI In the version of nws on system 29.97 nws, with microcode 669, on LISP Machine Six: Why does this system, supposedly a fresh nws world, have one of Danny's files in the editor when you first enter it?  Henry@MIT-AI 06/22/80 01:07:10 To: (BUG NWS) at MIT-AI In system 29.95 NWS, with microcode 669, on LISP Machine Four: What's the convention about returning EDGES for windows? Lisp Listeners seem to return a LIST of edges when sent a ':EDGES message, whearas ZWEI's windows [from ZWEI:(WINDOW-SHEET *WINDOW*)] return the edges as multiple values. I really don't care which way you do it, but how 'bout making the conventions consistent? Also, in OWS, there were useful messages RIGHT, LEFT, TOP, BOTTOM which seem to have disappeared. How about reinstating them.  Date: 21 June 1980 18:54-EDT From: Mike McMahon To: GLS at MIT-AI cc: BUG-NWS at MIT-AI Date: 21 JUN 1980 1455-EDT From: GLS at MIT-AI (Guy L. Steele, Jr.) Also, to make this work when you are dribbling to a file, I modified the code for DRIBBLE-IO to support READ-CURSORPOS also, by passing the buck to the previous I/O stream. It is essentially useless to make modifications to LMIO;DRIBBL. LMWIN;DRIBBL is a complete rewrite that works in a much more reasonable fashion and should have at least the old functionality in the ows.  Date: 21 June 1980 02:27-EDT From: Howard I. Cannon To: XCONOS at MIT-AI cc: BUG-NWS at MIT-AI, BUG-lispm at MIT-AI Date: 20 June 1980 23:24-EDT From: Alec Destry To: BUG-LISPM at MIT-AI At any time you are in the editor with the mouse in the scroll bar, type . You will get hung with NIL in the wholine and will have to cold-boot. This bug has been fixed in the source. Note that typing ESC/Control-Clear or Terminal/Control-Clear-Input will oftentimes unwedge such situations (this is of course an emergency measure only, and not a cure all). You might try this before the drastic action of warm or cold booting. Please report the bugs, though, since any time you need to use these keyboard commands a bug has been encountered. --Howard  MOON@MIT-MC 06/20/80 18:39:21 To: MMCM at MIT-AI CC: (BUG NWS) at MIT-MC Date: 20 June 1980 13:16-EDT From: Mike McMahon To: MOON at MIT-AI cc: BUG-NWS at MIT-AI Moon@MIT-AI 06/20/80 04:41:00 Should SHEET-BLINKER-LIST be an alist of blinker-names and blinkers? Or should people who want names have to have instance-variables in which to remember the named blinkers? It seems that there are ample facilities for storing objects already. Did you have some specific instance where this didn't work out well for you? It's all right, it turned out after I sent the mail that I had forgotten there is now a function called sheet-following-blinker. The problem was that that blinker which is automatically created doesn't get put in an instance variable. But it's not a problem.  Date: 20 June 1980 13:16-EDT From: Mike McMahon To: MOON at MIT-AI cc: BUG-NWS at MIT-AI Moon@MIT-AI 06/20/80 04:41:00 Should SHEET-BLINKER-LIST be an alist of blinker-names and blinkers? Or should people who want names have to have instance-variables in which to remember the named blinkers? It seems that there are ample facilities for storing objects already. Did you have some specific instance where this didn't work out well for you?  Moon@MIT-AI 06/20/80 04:41:00 To: (BUG NWS) at MIT-AI Should SHEET-BLINKER-LIST be an alist of blinker-names and blinkers? Or should people who want names have to have instance-variables in which to remember the named blinkers?  Moon@MIT-AI 06/20/80 03:38:15 Re: P.s. to previous about system-E To: (BUG NWS) at MIT-AI I used esc S to select the editor, from a Lisp listener, and now it is in this novel state where every time it reads something and echos it in the bottom of the screen area (c-X reading its dispatch character, string search reading a character) I have to click the mouse before it sees the character. In string search I typed ahead a whole lot of characters, then each time I clicked the mouse another character would echo down in the typein area!  Moon@MIT-AI 06/20/80 03:00:59 To: (BUG NWS) at MIT-AI In 29.95 nws we still haven't changed the kbd character format (moving the mouse bit) to allow for hyper and super  Moon@MIT-AI 06/20/80 02:35:20 To: (BUG NWS) at MIT-AI I made INSPECT global for the next world.  Moon@MIT-AI 06/20/80 01:37:28 To: (BUG NWS) at MIT-AI You probably already know this, but typing system-E in 29.95 nws does incredibly destroyed things. The most novel were putting up windows that refused to redisplay themselves, and getting into a state where it would only read one character from the keyboard until you clicked the mouse on the editor window displayed. I assume this will get fixed when the editor, echo area, and mini buffer get changed around however they are going to be.  MOON5@MIT-ML 06/19/80 19:54:52 To: (BUG NWS) at MIT-ML Typing ahead to a newly created supdup created with the mouse does not work. Evidently it rusn for a long time creating the window, processes, and so forth, then does a mouse-select which sends the typeahead to the wrong place. Clicking create on the system menu should file away the typeahead immediately, then anything typed after that should go to the new window created.  HIC@MIT-AI 06/19/80 03:48:57 To: (BUG NWS) at MIT-AI I fixed the bug where making a frame with a bit save array that had a peek in it with no bit save array would get into an infinite loop trying to hack the typeout window initially. This bug required adding a wrapper to :CHANGE-OF-SIZE-OR-MARGINS on ESSENTIAL-WINDOW-WITH-TYPEOUT-MIXIN that does a (WITH-SHEET-DEEXPOSED (TYPEOUT-WINDOW) . ,BODY). People who use typeout windows should make sure that this won't screw them -- I tested the editor and it doesn't cause any grief there. There is also this systemic problem about changing the edges of a window that has its typeout window exposed. What will usually happen is that the superior steps all over its typeout window in one way or another. I'm not really sure how to fix this, but perhaps some more systemic thing should be worked out (like maybe typeout windows should make themselves go away before they change their size. Of course, there is no systemic way to do this, so a message like :FLUSH-TYPEOUT-WINDOW should probably get defined...). Anyway, if anyone has any good ideas on this, let me know, or we can just punt the whole issue and fix it independantly for each thing, or not fix it at all as it is only a minor nuisance...  HIC@MIT-AI 06/18/80 22:11:46 To: (BUG NWS) at MIT-AI DONT-SELECT-WITH-MOUSE-MIXIN has been flushed from PANE-MIXIN. Please update your programs.  Taft@MIT-AI 06/17/80 12:03:17 To: (BUG NWS) at MIT-AI In system 27.90 nws, with microcode 667, on LISP Machine Four: If I select SPLIT-SCREEN mode from the system menu and then select EXISTING-WINDOW (I had one in mind) it feeps at me 3 or 4 times and goes off the deep end. Specifically it ends up in TYI with the run bar on, no mouse, in an apparently catonic state.  MOON@MIT-MC 06/17/80 02:30:32 Re: Automatic turning on and off of scrolling To: (BUG NWS) at MIT-MC I have attempted to modularize out the code I wrote for this for my choose-variable-values stuff into a separate mixin. Results are in AI:MOON;FOO1 >. I am still not entirely happy with it. Note that this also uses another mixin I had previously stuck into TSCROL (the one with the ridiculously long name). That should probably be removed and stuck into this one rather being separate. Can anyone fix this up more? See the comments in the file. (I haven't tested this code since I don't yet have a Lisp machine at home.)  MOON@MIT-MC 06/17/80 01:48:09 Re: :DOCUMENT message To: (BUG NWS) at MIT-MC I give up! I confess my error! Let's punt this stupid message, it's obviously never going to be implemented.  Date: 16 June 1980 19:07-EDT From: Mike McMahon Sender: MMcM at CADR6 at MIT-AI Subject: ztop To: HENRY at MIT-AI cc: BUG-ZWEI at MIT-AI, BUG-NWS at MIT-AI Obviously you view this according to a less conventional model. ZTOP mode is a read-eval-print loop implemented as a major mode, whereby it reads input and prints to a buffer that receives typein in the normal fashion. It shouldn't be too hard to implement commands to simulate the other features of your old thing; such as printing an evaluation value into this buffer. I don't understand what is useful about printing the result of a compilation, unless what you really mean is that you want the Compiler Warnings buffer to be in ZTOP mode, which is quite easy.  HIC@MIT-AI 06/16/80 06:53:23 To: (BUG NWS) at MIT-AI Two tings: A) SYSTEM puts the currently selected window at the end of PREVIOUSLY-SELECTED-WINDOWS, but this causes things that select to the previous window when done (like SUPDUP) to select a random window. Perhaps it should put it at end only if (TYPEP SELECTED-WINDOW ) which will cycle through sort of in the right fashion... B) I got into a situation where I selected another window while in the mini-buffer, which subsequently got deselected. Unfortunatly, it was left in the ring and... Well, perhaps ZWEI-WINDOW-WITH-TYPEOUT-UNSELECTABLE should return NIL for its :ALIAS-FOR-SELECTION or return its superior or something other than itself, so you don't get screwed. Better yet, perhaps it should remove itself from PREVIOUSLY-SELECTED-WINDOWS when it gets deselected (or perhaps it should simply get deactivated, which would sort of do the right thing).  Taft@MIT-AI 06/16/80 02:54:42 To: (BUG NWS) at MIT-AI In system 27.92 NWS, with microcode 667, on Xerox Machine 1: You may already know about this one, but in the Inspector if I click mouse middle as if to go to another screenfull(?) on the large bottom inspection window, but miss and click while the mouse is just outside the bottom border of this window, I get: -> Error in the mouse process, using the cold load stream <-- >>ERROR: The object # received a DOCUMENT message which went unclaimed. ...  Moon@MIT-AI 06/16/80 01:08:59 To: (BUG NWS) at MIT-AI In the version of nws on system 27.93 NWS, with microcode 667, on LISP Machine Six: esc 0 F followed immediately by typeahead still fucks up and sends some of the typeahead to the currently selected window and some to the finger window.  Moon@MIT-AI 06/16/80 00:42:00 To: (BUG NWS) at MIT-AI AI:MOON;FOO > is a function which you can give a list of special variables to, and the user may edit their values with the mouse. There are of course a few additional features in it. This seems like something a lot of application programs would want to be able to use. Please review it for style and taste and install it. I'm not sure if it belongs in TSCROL or in a separate file. You need 27.93 and the latest TSCROL to run it. PLOT-EXAMPLE is an example frob that uses it.  Moon@MIT-AI 06/16/80 00:27:56 To: (BUG NWS) at MIT-AI The labels on margin-choice-boxes are displayed in the current font. This causes random behavior in windows that actually use multiple fonts. I think it should either use (aref font-map 0) or a specifiable font.  Moon@MIT-AI 06/15/80 23:21:53 To: (BUG NWS) at MIT-AI In the version of nws on system 27.93 NWS, with microcode 667, on LISP Machine Six: Things wrong with the inspector: Minor - there should be a way to inspect something in the second window, leaving the big window showing its current contents. Very often you put the main object of interest in the big window, and want to inspect several of its components in succession. More important - the modify mode is unnecessarily difficult to use. For one thing it's a pain to have to go click modify in the menu each time one wants to modify; I think this would better be permanently assigned to a button. And consider this example; I had a window some of whose internal data, in the form of list structure, I wished to modify. So I inspected the window, but "modify" mode refused to recognize the thing I wanted to modify while the window was inspected; it forced me to go inspect the particular piece of list structure first. You should be able to modify anything that's on the screen, unless (like symbol pnames) there is a good reason for it to be read-only. I still want to lobby for inspect of an unknown type to call describe. It would of course be a nice frill if describe's output were mouse sensitive, but the important thing is to be able to get information at all. A related problem is that inspect of a fef only shows you the code; you would like also to be able to see the header information, which describe will show. The same applies to arrays. Note that once we implement the :print message, which the prin1 and princ functions (but not si:print-object) call if the stream handles it, before trying to print using characters, the inspector can interface much more nicely to the rest of the world, since it can simply call any sort of description routine, and make the output automatically mouse-sensitive without need for modification of the description routine. This of course doesn't implement modification, which is less important. It would be real nice if modification could be implemented by a scheme where you would ask the routine responsible for the object (the object itself in the case of entities, instances, and named-structures) to modify the "nth" slot of the object to a specified value, where "n" would be the ordinal number of the call to prin1 or princ in the description of that object. To help catch bugs where "n" is not correct (that is, inconsistency between corresponding description and modifcation routines), the old value of the slot should be passed in and checked.  HIC@MIT-AI 06/15/80 18:12:02 To: (BUG NWS) at MIT-AI I changed SHEET-FORCE-ACCESS so that it always forces access if there is a screen array, and never if there is no screen array. I believe that this is more the right thing, but I'd appreciate it if you'd look it over and make sure it won't break anything. The old condition was a bit random anyway.  MOON@MIT-MC 06/15/80 17:03:24 To: MMcM at MIT-AI CC: (BUG NWS) at MIT-MC Date: 15 June 1980 16:39-EDT From: Mike McMahon Sender: MMcM at CADR8 at MIT-AI To: MOON at MIT-AI cc: BUG-NWS at MIT-AI Moon@MIT-AI 06/15/80 04:53:05 Multiple-choice-windows don't get deactivated. If you make a Lisp listener half the height of the screen, then call the editor, write out your files, then c-Z, the editor is buried but not the multiple-choice frob it used, so that comes back to the screen if the Lisp listener doesn't cover it. When done, they go a :SET-STATUS to whatever they were originally. I don't have any problems either manually or via the scenario you describe. Are you sure you didn't mess with that resource in some way? I don't think so. Maybe there's a missing unwind-protect? At least once in that session I got a dir full out of a save and hit abort or eh c-z. Of course that was after the choice window had already deexposed. Oh, also, there was the screw mentioned in a previous bug report where I got a qsend while a multiple-choice window was up, which did a mouse-select (we assume) and deexposed the choice window. I then hit abort since the editor was still in CHOOSE state. Probably this did it, if there is a missing unwind-protect. Can WITH-RESOURCE take an extra argument which is a message to send when done? Or can DEFRESOURCE specify that message? So that window resources can get deactivated automatically.  Date: 15 June 1980 16:39-EDT From: Mike McMahon Sender: MMcM at CADR8 at MIT-AI To: MOON at MIT-AI cc: BUG-NWS at MIT-AI Moon@MIT-AI 06/15/80 04:53:05 Multiple-choice-windows don't get deactivated. If you make a Lisp listener half the height of the screen, then call the editor, write out your files, then c-Z, the editor is buried but not the multiple-choice frob it used, so that comes back to the screen if the Lisp listener doesn't cover it. When done, they go a :SET-STATUS to whatever they were originally. I don't have any problems either manually or via the scenario you describe. Are you sure you didn't mess with that resource in some way?  MOON@MIT-MC 06/15/80 15:43:54 Re: Organizational problems To: (BUG NWS) at MIT-MC I have a kind of window which does something new, namely turn scroll bar and margin-scroll-regions on and off depending on whether what it wants to displlay fits. This uncovered lots of problems, which I have mostly fixed although maybe not in the best possible fashion (had to have a way of turning margin-scroll-regions off; can't actually take them out of the REGION-LIST or when they are put back in they get put back in in the wrong place, not according to order of method combination. FLASHY-SCROLLING-MIXIN just looks at SCROLL-BAR-P, which is nice, but things aren't organized so that margins can look at SCROLL-BAR-P and redefine themselves [we don't have a general constraint propagation system.]) Anyway, what this mail is really about is that I do several margin redefinitions (2 I guess) and then a set-inside-size and then a set-items (in the TSCROL sense). Each of those causes a redisplay. I kludge around this by not having a bit-save array and doing with-sheet-deexposed, which defers the redisplay until after all the changes have been done. But this wouldn't work if there was a bit array; probably a way of deferring redisplay (refresh and refresh-margins) should be put in. One way would be a defer flag and change flags for the inside and margins. Another way would be to bind off the bit array, then at the end put it back, possibly adjusting its size. I guess it would be nicer if it could avoid reparsing all the margin specs "n" times, and defer that to the end, too. The problem here is that I can't easily convert a bunch of set-this and set-that messages into a single :REDEFINE-MARGINS message. This deferring is much harder to do, though; I just thought I ought to mention it.  Moon@MIT-AI 06/15/80 04:53:05 To: (BUG NWS) at MIT-AI Multiple-choice-windows don't get deactivated. If you make a Lisp listener half the height of the screen, then call the editor, write out your files, then c-Z, the editor is buried but not the multiple-choice frob it used, so that comes back to the screen if the Lisp listener doesn't cover it. Does killing a window remove it from its resource, or, actually, prevent it from being put back in the resource when the owning process exits through the WITH-RESOURCE? This would seem to be a good idea.  Moon@MIT-AI 06/15/80 04:40:13 Re: Things I don't want to fix right now To: (BUG NWS) at MIT-AI A couple times I got a window without a bit-save array into a weird state where output-hold wasn't on but it didn't have a screen array; naturally this causes it to err out from the microcode sheet output functions. Hic suggests sheet-force-access should have some of its conditionals rearranged. If you get a qsend while in kill-or-save-buffers, after leaving the qsend someone mouse-selects the editor buffer, disappearing the multiple choice window while the editor is still using it. One theory is that for temporary multiple-choice-windows, with an abort button, deexposing it should push abort. But why did it mouse-select anyway?  Moon@MIT-AI 06/15/80 02:04:49 To: (BUG NWS) at MIT-AI In the version of nws on system 27.93 NWS, with microcode 667, on LISP Machine Six: If an error occurs when there is no selected window, it hangs uselessly waiting for a selected window. It has an informative waitstate which however does not show up in the who-line since there is no selected window. What it should do is pop up a notification box when there is no selected window, possibly waiting a few seconds first in case one is going to get selected.  HIC@MIT-AI 06/14/80 19:46:18 To: (BUG NWS) at MIT-AI CC: XCONOS at MIT-AI I believe I have fixed the timing screw that provoked XCONOS' bug with the inspector.  Date: 13 June 1980 20:44-EDT From: Mike McMahon To: MOON at MIT-MC cc: BUG-NWS at MIT-AI MOON@MIT-MC 06/13/80 15:54:49 Re: Suggestions for the nws (defmacro sheet-line-number (&optional (sheet 'self) ypos) It is called SHEET-LINE-NO and was installed already in this week's set of gratuitous changes. The convention that already exists is for SHEET being NIL to mean as if called within SELF, since there are potential cases where SELF is right but the instance variables might not be bound, this could be changed if we decide the several (SHEET-LINE-NO NIL Y)'s that exist are distasteful. There should be a MOUSE-SENSITIVITY-MIXIN abstracted from part of MOUSE-SENSITIVE-TEXT-SCROLL-WINDOW. Would this be useful in enough places to be worth putting in? I don't see why not. There should be a flavor called WINDOW-WITHOUT-LABEL, which is like WINDOW but does not include the label flavors. I believe there is already someplace. NIL in the args to :SET-CURSORPOS should mean don't change that coordinate, this seems to be commonly wanted. This is the case i think.  MOON@MIT-MC 06/13/80 17:00:52 To: (BUG NWS) at MIT-MC What should be the character that gets you the screen editor from the system key?  MOON@MIT-MC 06/13/80 16:47:02 Re: Suggestion To: (BUG NWS) at MIT-MC Suppose mouse-specify-rectangle (the function with the upper-left and lower-right corners) was changed so that if you put a corner within 5 or 6 dots of a "defined point", it "latches" exactly to that point. It's hard to position the mouse exactly while simultaneously clicking it. Defined points would be the corners of the available area (the mouse-sheet), and also corners and edges of exposed windows.  MOON@MIT-MC 06/13/80 15:54:49 Re: Suggestions for the nws To: (BUG NWS) at MIT-MC (defmacro sheet-line-number (&optional (sheet 'self) ypos) (if (eq sheet 'self) `(// (- ,(or ypos `cursor-y) (sheet-inside-top)) (sheet-line-height)) `(// (- ,(or ypos `(sheet-cursor-y ,sheet)) (sheet-inside-top ,sheet)) (sheet-line-height ,sheet)))) or something like this. I haven't debugged the macrology. Is the conditionalization necessary, or do the accessor macros notice when their arg is self? And should the ones generated by FLAVOR itself be improved to do this? In TSCROL there are some daemons on :INSERT/DELETE-ITEM which should be daemons on :INSERT/DELETE-LINE (in DISPLAYED-ITEMS-MIXIN). There should be a MOUSE-SENSITIVITY-MIXIN abstracted from part of MOUSE-SENSITIVE-TEXT-SCROLL-WINDOW. This would provide for windows with rectangular areas sensitive to the mouse, and would supply the "blinker" (hollow rectangular by default) that highlights the sensitive area nearest to the mouse. This code seems to be written in several places now. There would be REQUIRED-METHODS of :MOUSE-SENSITIVE-ITEM which translates (x,y) to (item,type,left,top,right,bottom), and :MOUSE-CLICKS-ITEM which gets (item,type,bd) and does something useful (the default would be to force-kbd-input (list type item self bd).) Would this be useful in enough places to be worth putting in? I think it would make a number of "user programs" easier. You could also have a combination built on the above mixin and text-scroll-window, where the user would supply a method which would be given an item (of the text-scroll variety) and mouse x coordinate, and would return values like :MOUSE-SENSITIVE-ITEM. There should be a flavor called WINDOW-WITHOUT-LABEL, which is like WINDOW but does not include the label flavors. A lot of things seem to do this by using WINDOW with :LABEL NIL. NIL in the args to :SET-CURSORPOS should mean don't change that coordinate, this seems to be commonly wanted. In the drawing program I have a 1-line window called the "mouse prompt". It tells what each of the 3 mouse buttons does. I've found this quite useful. If we ever bite the bullet and expand the who-line to 2 lines, I think we should put a mouse prompt in it. This area would just show 3 brief 1- or 2-word clues as to what each of the mouse buttons does. I'm not sure what to do about double clicks. We don't want to be too verbose in the mouse prompt, since it will take up screen space, cpu time to update it, and most importantly brain time to read it or ignore it. If we make a 2-line wholine, the lower line should be related to the immediate current interaction, and the upper line should be more "global" information. I would suggest a layout like: date/time username idletime meters filestate processname package runstate meters mouseprompt The meters would be things like paging rate and fraction of machine time expended on: process in the wholine, "user" processes, background" processes, scheduler, GC, microcode overhead. These meters don't exist now, but I intend to put them in one of these days. At the bottom of the terminal/help output should be a guide to what all the stuff in the wholine is.  JLK@MIT-MC 06/13/80 11:11:51 To: (BUG nws) at MIT-AI I find it somewhat unflavorful for various things like TERMINAL F, SYSTEM P, etc. to generate these huge full-screen windows. It would be nice for it to only use as much of the screen as it needs (I realize this may require some heuristics). TERMINAL ?, SYSTEM ? are particular examples where the size needed should be easily predictable. I typically prefer information windows to sort of pop-up and then go away leaving the screen the way it was (like the ? and NAME windows do). Note for instance that when you type SYSTEM P and then Q, you dont get back to your previous screen configuration without a lot of mousing. While I am complaining, it is obvious to everyone that your sends msgs want to be buffered (saved) somehow so you can look at them again. Also, you may want to defer responding to a message, but then get back to it. Occassionaly I want to respond to a send using mail, but I don't have this option. It would be convenient if SEND and MAIL (and someday, RMAIL) were in the main window-creation menu. This applies to NWS 27.92 on CADR 7  RWK@MIT-AI 06/13/80 03:00:39 Re: Bugs, gripes, and suggestion To: (BUG NWS) at MIT-AI In system 28.82 nws, with microcode 666, on LISP Machine Four: [If any of this is due to running microcode 666 (number of the beast, and all) instead of 667, please tell me how to get the right microcode, and shame on you for not making that automatic!] I created two SUPDUP windows (all other windows killed, Select showing just that tiny box of an empty menu), and selected EXPAND ALL in the screen editor. It flashed twice, presumably because it can't expand a SUPDUP window, and left me in "Temp Lock" state. After some futzing around with mouse-right I managed to get back to the screen editor, and tried "Move Multiple". This set my wholine state to "Pick Something", and left me with no mouse blinker. After trying to find the mouse blinker for a while, I gave up and hit mouse-left blindly. Again, two flashes, leaving me in LOCK. At this point I could no longer get a menu, and ESCAPE ? wouldn't work to find out how to reset the locks, so I gave up and warm booted. Earlier, I was playing with the inspector, (neat hack) and did a long APROPOS. I got tired of waiting, so I tried to get to the system menu, figuring I'd just select some other window and let that one sit de-exposed for a while. Unfortunately, it's about impossible to get to the system menu while something is running. So I typed ESCAPE ?, which left me waiting for keyboard input, and moused my way out. But response remained terrible. With difficulty, I got into PEEK and looked at the windo-system heirarchy, and noted that the inspector interaction window remained "exposed" evn though the inspector itself did not. Eventually response got better and I was able to get back to the window with the APROPOS, and it seemed to have continued running to completion! It would seem that a de-exposed inspector frame should de-expose it's component windows, no? At any rate, response to mouse keys and motion while there's something else running is unusably poor; I hope there's something which can be done about it. A more general question: Is there generally any way to find out which mouse keys have useful functions attached and some documentation for them? Also what actions like funny scroll modes, etc. are possible, and how to use them? If not, there should be. It took me forever to be able to reliably enter the down-arrow and up-arrow scroll frob in the inspector, even after I guessed what it was for. I still don't know under what conditions it goes into that mode, but have observed that it works better if I sort of wave the mouse around in the midde of the edge I want to scroll toward. You can dismis this complaint as ignorance, but I think the system should be more helpful to the ignorant. Perhaps or ESCAPE or an entry in the system menu should give a pop-up menu, one of who's options is to tell you the state of the mouse buttons BEFORE you entered the pop-up menu. This menu could be a general repository of helpful information. Like it could have available documentation on the inspector while in the inspector (I never did figure out what DeCache was for, nor could I figure out anywhere to find it out.). Another entry in this menu could ask for a symbol and give you its documentation. It would be very good if all a person really needed to know to use a LISP machine were to hit mouse-left twice, and help could be found from there. Currently, ignorance is a big barrier to effective use of the LISPM, and even an up-to-date manual wouldn't be as convenient as a little self-documentation.  MOON@MIT-MC (Sent by CENT@MIT-MC) 06/12/80 00:38:13 To: (BUG NWS) at MIT-MC CC: rms at MIT-AI I think it would be clearer for Select when there are no windows to show an empty menu than to beep; random unexplained beeps are not such a good idea. (There are already too many in the system in my opinion.) It would of course be even better if it told you what was happening rather than dropping hints.  RMS@MIT-AI 06/12/80 00:43:54 To: HIC at MIT-MC CC: (BUG NWS) at MIT-AI Menus such as Select and Layouts should contain a label saying "acts immediately". I don't agree. Part of knowing how to use the system is knowing this information. That is true, but part of making a system easy to use is making it tell the user these things instead of asking him to remember. Plato does a great deal of this, telling the user which keys he can use to at the moment to do various things even though there are conventions for it, and it really made the system easier for a beginner to use. Also, it seems to me that it is pretty clear when something is a terminal menu -- namely, it mentions something by its "name" -- the name of a window or of a layout. It can't help being clear to a person who is familiar with the system, but additional help is useful for someone who is not.  Date: 11 June 1980 20:08-EDT From: Howard I. Cannon Subject: Comments on TSCROL To: MMcM at MIT-AI cc: MOON at MIT-MC, BUG-NWS at MIT-AI Well, since you obviously don't agree with my ideas on modularity I won't go back and change TSCROL again, but I think the daemons should have been left like they were. I will look into the gray stuff interacting with insert/delet item.  Date: 11 June 1980 19:45-EDT From: Howard I. Cannon To: ACW at MIT-AI cc: BUG-NWS at MIT-AI Date: 11 June 1980 06:40-EDT From: Allan C. Wechsler To: BUG-LISPM at MIT-AI In system 27.92 nws, with microcode 667, on LISP Machine Six: Context: Just logged in. Action: Tried to do a split-screen with a Peek on the top and an Editor on the bottom. Symptom: Hung in "activate" state. --- Wechsler Fixed in the source.  Date: 11 June 1980 16:33-EDT From: Mike McMahon Sender: MMcM at CADR6 at MIT-AI Subject: Comments on TSCROL To: MOON at MIT-MC cc: BUG-NWS at MIT-AI Date: 06/11/80 02:20:30 From: MOON at MIT-MC TOP-ITEM is a settable instance variable of TEXT-SCROLL-WINDOW, but setting it doesn't work since it doesn't do a SCROLL-REDISPLAY. This was intended for setup only. Look at (FUNCTION-TEXT-SCROLL-WINDOW :SETUP). I changed it to SETQ. (TEXT-SCROLL-WINDOW :BEFORE :INIT) explicitly sets :BLINKER-P to NIL in the INIT-PLIST. I have flamed about this in the past. This sort of thing should be done via the DEFAULT-INIT-PLIST. I have a program which wants to use TEXT-SCROLL-WINDOW as a module to provide some capabilities for a window. It also wants to have a cursor-following blinker whose visibility is NIL when TEXT-SCROLL-WINDOW is being used, but which gets turned on in certain situations. I cannot do this because TEXT-SCROLL-WINDOW gratuitously gets rid of the blinker. It would be reasonable, I guess, to do this explicit putprop for things which would destroy the proper operation of the window (e.g. the :MORE-P in this case), but it is not reasonable to do it for other things. I moved :BLINKER-P, but maintain my previous position on this as a stylistic device for :MORE-P and :SAVE-BITS. There are a number of things done as daemons for reasons I don't understand, e.g. (TEXT-SCROLL-WINDOW :AFTER :SET-ITEMS), This is because it acted as a settable instance variable, for no particular reason. (TEXT-SCROLL-WINDOW :AFTER :REDISPLAY), (TEXT-SCROLL-WINDOW :AFTER :SCROLL-REDISPLAY), This is someone else's idea of modularity, obviously added as an afterthought, and not by me that i know of. I have changed it, and someone can change it back if there was indeed a valid reason. (MOUSE-SENSITIVE-TEXT-SCROLL-WINDOW :AFTER :ITEM). Ditto. (TEXT-SCROLL-WINDOW :DELETE-ITEM) and (TEXT-SCROLL-WINDOW :INSERT-ITEM) sometimes but not always do a :NEW-SCROLL-POSITION. They should do one always, after the COND. Well, not actually, but i added one to the clause of the COND that needed it and didn't have it. The method (TEXT-SCROLL-WINDOW :SCROLL-BAR-P) is completely wrong. It should be that the number of items is more than the height of the screen OR top-item > 0. Fixed. In several places there is an option :DEEXPOSED-TYPEOUT-ACTION (:EXPOSE-FOR-TYPEOUT) This is the default now. Fixed. (TEXT-SCROLL-WINDOW-TYPEOUT-MIXIN :WRAPPER :REDISPLAY) is written in a disgusting way. I suggest that the IGNORE in the arglist be changed to ARGS and that fields of ARGS be SETF'ed (it would of course be nice to put in macrology so that you can do SETQ's of args and the right thing would happen.) As i recall, this generated ridiculous code, i changed it anyway, though. DISPLAYED-ITEMS-TEXT-SCROLL-WINDOW needs a daemon on :CHANGE-OF-SIZE-OR-MARGINS to change the size of its DISPLAYED-ITEMS array. This should be arranged to go off before the corresponding :REDISPLAY. Things that use this seem to include it in the proper order. (MOUSE-SENSITIVE-TEXT-SCROLL-WINDOW :ITEM) uses the free variable *LINE-NO-BEING-PRINTED*, a crock associated with an entirely unrelated flavor. It should compute this value from CURSOR-Y of course. But this method appears to be brain-damaged anyway, since it does not fit in at all with the rest of this system of flavors; it types out rather than putting something into the items array for redisplay's benefit. You must mean :PRINT-ITEM, which would account in part for your gross confusion as to its purpose, since it is the message *called* by redisplay in all cases. In the mouse-sensitive case, it can sometimes send a :ITEM message as well inside the print function. The other flavor to use the variable is also a direct inferior. I have nevertheless rearranged the code somewhat to do the computation again as you say. (MOUSE-SENSITIVE-TEXT-SCROLL-WINDOW :MOUSE-BUTTONS) should perhaps not encode the buttons, so that it behaves like Lisp listener. Alright. The :AFTER :REFRESH and :AFTER :SET-ITEMS methods of TEXT-SCROLL-WINDOW-EMPTY-GRAY-HACK should be replaced by a single :AFTER :REDISPLAY method, which would both be more modular and fix a number of bugs (having to do with the window being not exposed and with the :DELETE-ITEM message). This mixin has another bug anyway which is that if you have an empty such window and send it a :APPEND-ITEM most of the gray does not go away. Someone responsible for the append-item and delete-item messages should figure this out. The method (MARGIN-REGION-MIXIN :SET-BORDERS) is presumably a typographical error and is supposed to be called :SET-REGION-LIST. Yes. In (MARGIN-REGION-MIXIN :AFTER :MOUSE-MOVES) there is an extraneous (MOUSE-SET-BLINKER-CURSORPOS). This is obviously due to the other recent modularity changes you see around it. The code in MARGIN-SCROLL-REGION that binds the margins to 0 and hacks the font is gross and kludgiferous. There is no other, more general, mechanism for doing this.  Date: 11 June 1980 13:33-EDT From: Howard I. Cannon To: RMS at MIT-AI cc: BUG-NWS at MIT-AI Date: 11 June 1980 05:14-EDT From: Richard M. Stallman To: BUG-NWS at MIT-AI It seems to the trend that most menu operations don't actually do anything immediately when selected. It looks like there's a convention for mouse-right to abort things which ask the user to specify a window or a rectangle, and this is a good idea. If not all operations are going to be abortable in this way, it might be good to have a convention for something to appear in the menu to indicate which operations are not. Perhaps an exclamation mark. In my opinion the use of a magic character in the item name has always looked bad, and is merely confusing. Menus such as Select and Layouts should contain a label saying "acts immediately". I don't agree. Part of knowing how to use the system is knowing this information. Also, it seems to me that it is pretty clear when something is a terminal menu -- namely, it mentions something by its "name" -- the name of a window or of a layout. Therefore, I see no need for this. Also, most, if not all, of these terminal menus do non-destructive things -- except some things in the Other menu, which I agree should be flushed.  Date: 11 June 1980 13:30-EDT From: Howard I. Cannon To: RMS at MIT-AI cc: BUG-NWS at MIT-AI Date: 11 June 1980 04:57-EDT From: Richard M. Stallman To: BUG-NWS at MIT-AI I think that the COLOR-WINDOW menu item should be named "Create on Other Screen" or some such thing, because my first guess was that it would let me change the color of a window (I think this would be a good operation to add). It ought to create a window on the CPT when invoked on the color screen. Perhaps it should -- but it is basically a hack. I might flush it now that it is easy enough to switch screens with the other menu operation. It is potentially confusing that Kill in the Other menu doesn't work the same way as Kill in the Edit Screen menu. Probably all such operations in the Other menu should be made to choose the window afterward the way the Edit Screen operations do. Yes, Kill in the Other menu should be flushed. We tried killing all the windows there were. Then we discovered that Select created a very tiny empty menu! It was amusing. But it might be better for Select to beep instead. Probably.  Date: 11 June 1980 13:27-EDT From: Howard I. Cannon To: RMS at MIT-AI cc: BUG-NWS at MIT-AI Date: 11 June 1980 04:56-EDT From: Richard M. Stallman To: BUG-NWS at MIT-AI We discovered that killing a SUPDUP window does not remove its pair of processes from the active list, whereas killing a lisp listener does remove its process from the list. I guess that's a bug. We also noticed that there were two processes named MOUSE. One didn't seem to be doing anything, because we FLUSHed it and warm booted, and it stayed flushed, and everything worked. One of those is the old window system's mouse process, which we don't care about. That will go away when a world with only nws is built. Also, we saw that the screen-manager-background process was always active. Since the system-menu process doesn't stay active all the time, it would seem that this is not necessary, and it would be a feature if it were only active when doing something. In fact, why doesn't the system-menu process do that work? The screen manager background process is always needed, just as the chaos net background process is. It doesn't get used all that often, but runs when it needs to.  RMS@MIT-AI 06/11/80 05:14:22 To: (BUG NWS) at MIT-AI It seems to the trend that most menu operations don't actually do anything immediately when selected. It looks like there's a convention for mouse-right to abort things which ask the user to specify a window or a rectangle, and this is a good idea. If not all operations are going to be abortable in this way, it might be good to have a convention for something to appear in the menu to indicate which operations are not. Perhaps an exclamation mark. Menus such as Select and Layouts should contain a label saying "acts immediately".  RMS@MIT-AI 06/11/80 04:57:07 To: (BUG NWS) at MIT-AI I think that the COLOR-WINDOW menu item should be named "Create on Other Screen" or some such thing, because my first guess was that it would let me change the color of a window (I think this would be a good operation to add). It ought to create a window on the CPT when invoked on the color screen. It is potentially confusing that Kill in the Other menu doesn't work the same way as Kill in the Edit Screen menu. Probably all such operations in the Other menu should be made to choose the window afterward the way the Edit Screen operations do. We tried killing all the windows there were. Then we discovered that Select created a very tiny empty menu! It was amusing. But it might be better for Select to beep instead.  RMS@MIT-AI 06/11/80 04:56:12 To: (BUG NWS) at MIT-AI On the default band on CADR-2, ACW and I were playing with PEEK. We discovered that killing a SUPDUP window does not remove its pair of processes from the active list, whereas killing a lisp listener does remove its process from the list. We also noticed that there were two processes named MOUSE. One didn't seem to be doing anything, because we FLUSHed it and warm booted, and it stayed flushed, and everything worked. Also, we saw that the screen-manager-background process was always active. Since the system-menu process doesn't stay active all the time, it would seem that this is not necessary, and it would be a feature if it were only active when doing something. In fact, why doesn't the system-menu process do that work? The menu for operating on processes in the PEEK window is neat. However, the "un-arrest" operation is useless, because an arrested process doesn't appear in the list. Perhaps there should be arrest and un-arrest operations in the menu for windows in the W option. I think that the horizontal space between the process name and its state should be less. It is so wide it even looks a little bad, not to mention requiring a wider window than is really necessary.  MOON@MIT-MC 06/11/80 02:20:30 Re: Comments on TSCROL To: (BUG NWS) at MIT-MC I've been reading this and have some comments and questions. TOP-ITEM is a settable instance variable of TEXT-SCROLL-WINDOW, but setting it doesn't work since it doesn't do a SCROLL-REDISPLAY. (TEXT-SCROLL-WINDOW :BEFORE :INIT) explicitly sets :BLINKER-P to NIL in the INIT-PLIST. I have flamed about this in the past. This sort of thing should be done via the DEFAULT-INIT-PLIST. I have a program which wants to use TEXT-SCROLL-WINDOW as a module to provide some capabilities for a window. It also wants to have a cursor-following blinker whose visibility is NIL when TEXT-SCROLL-WINDOW is being used, but which gets turned on in certain situations. I cannot do this because TEXT-SCROLL-WINDOW gratuitously gets rid of the blinker. It would be reasonable, I guess, to do this explicit putprop for things which would destroy the proper operation of the window (e.g. the :MORE-P in this case), but it is not reasonable to do it for other things. There are a number of things done as daemons for reasons I don't understand, e.g. (TEXT-SCROLL-WINDOW :AFTER :SET-ITEMS), (TEXT-SCROLL-WINDOW :AFTER :REDISPLAY), (TEXT-SCROLL-WINDOW :AFTER :SCROLL-REDISPLAY), (MOUSE-SENSITIVE-TEXT-SCROLL-WINDOW :AFTER :ITEM). Why is certain code taken out into a daemon instead of being written in the primary method along with the other code? Perhaps I am just being too paranoid about "there are too many combined-methods", but it does seem unnecessary to have these daemons. (TEXT-SCROLL-WINDOW :DELETE-ITEM) and (TEXT-SCROLL-WINDOW :INSERT-ITEM) sometimes but not always do a :NEW-SCROLL-POSITION. They should do one always, after the COND. An example of a bug caused by this is if you have something with a "more above" margin scroller, which is set to item 1, and you delete item 0, the scroller does not change to "Top", because the display does not change. The method (TEXT-SCROLL-WINDOW :SCROLL-BAR-P) is completely wrong. It should be that the number of items is more than the height of the screen OR top-item > 0. In several places there is an option :DEEXPOSED-TYPEOUT-ACTION (:EXPOSE-FOR-TYPEOUT) This is the default now. (TEXT-SCROLL-WINDOW-TYPEOUT-MIXIN :WRAPPER :REDISPLAY) is written in a disgusting way. I suggest that the IGNORE in the arglist be changed to ARGS and that fields of ARGS be SETF'ed (it would of course be nice to put in macrology so that you can do SETQ's of args and the right thing would happen.) DISPLAYED-ITEMS-TEXT-SCROLL-WINDOW needs a daemon on :CHANGE-OF-SIZE-OR-MARGINS to change the size of its DISPLAYED-ITEMS array. This should be arranged to go off before the corresponding :REDISPLAY. (MOUSE-SENSITIVE-TEXT-SCROLL-WINDOW :ITEM) uses the free variable *LINE-NO-BEING-PRINTED*, a crock associated with an entirely unrelated flavor. It should compute this value from CURSOR-Y of course. But this method appears to be brain-damaged anyway, since it does not fit in at all with the rest of this system of flavors; it types out rather than putting something into the items array for redisplay's benefit. (MOUSE-SENSITIVE-TEXT-SCROLL-WINDOW :MOUSE-BUTTONS) should perhaps not encode the buttons, so that it behaves like Lisp listener. The :AFTER :REFRESH and :AFTER :SET-ITEMS methods of TEXT-SCROLL-WINDOW-EMPTY-GRAY-HACK should be replaced by a single :AFTER :REDISPLAY method, which would both be more modular and fix a number of bugs (having to do with the window being not exposed and with the :DELETE-ITEM message). This mixin has another bug anyway which is that if you have an empty such window and send it a :APPEND-ITEM most of the gray does not go away. The method (MARGIN-REGION-MIXIN :SET-BORDERS) is presumably a typographical error and is supposed to be called :SET-REGION-LIST. In (MARGIN-REGION-MIXIN :AFTER :MOUSE-MOVES) there is an extraneous (MOUSE-SET-BLINKER-CURSORPOS). The code in MARGIN-SCROLL-REGION that binds the margins to 0 and hacks the font is gross and kludgiferous.  HIC@MIT-AI 06/10/80 23:38:21 To: (BUG NWS) at MIT-AI In system 27.92 nws, with microcode 667, on LISP Machine Two: MARGIN-REGION-MIXIN has a dummy definition for mouse-moves, which all the time ends up shadowing the real ones. Why don't we move this dummy definition all the way down into some default, or break it out into some other flavor and make that included (this is basically a reminder).  ACW@MIT-AI 06/10/80 05:54:39 Re: Documentation To: (BUG NWS) at MIT-AI NWSOPR is now obsolete. Most of its contents have been moved or rearranged into OPERAT >. Make changes to this file now instead of the old one. I am still working on it, however; perhaps blatant problems should just be brought to my attention rather than just fixed. ---Wechsler  HIC@MIT-MC 06/10/80 02:43:24 To: (BUG NWS) at MIT-MC It is quite clear that use of the color screen causes significant slowdowns in screen management (or related things, like changing size of a window) on the black and white screen after a while. It is wierd, and I don't understand it. This is just a reminder that it is probably a fairly serious bug and should be looked into asap.  HIC@MIT-AI 06/08/80 21:02:25 To: (BUG NWS) at MIT-AI In system 27.91 nws, with microcode 667, on LISP Machine Six: Notification doesn't work when an editor window is selected because (ZMACS-WINDOW :NOTIFY-STREAM) message accesses special variables that are not bound in the callers stack group. It was not immediatly obvious to me how to fix this, so I didn't.  MOON@MIT-MC 06/07/80 18:36:20 Re: LMDOC;MANUAL OUTLIN To: ACW at MIT-AI CC: (BUG NWS) at MIT-MC I agree that we need documentation on the user tools. I don't think much more detail than NWSOPR is required for this. These tools are generally easy to figure out by using them, once you have the basic idea down. The much more important need for detailed documentation is for programmers. The programmer's interface to the new window system is very complex. Many users will need to use it, and unlike the tools they cannot use it at all without either documentation or hand-holding by the authors. I think if you want to be useful this summer you should concentrate on this aspect. Probably the part where you have the strongest talents is in explaining the conventions (both the general conventions and the conventions, purpose, and organization of the many specific features), although the mechanical enumeration of functions, variables, flavors, and messages is also necessary. I would be unhappy if you spent a significant amount of the summer polishing NWSOPR and not working on the documentation we really need.  cube@MIT-AI 06/06/80 23:01:58 To: (BUG NWS) at MIT-AI In the version of nws on system 27.84 nws, with microcode 667, on LISP Machine Two: Try typing (ed) at the inspector. It displays the editor then comes back to the inspector immediately.  JLK@MC (Sent by KLM) 06/02/80 12:11:11 To: (BUG NWS) at MIT-AI In the version of NWS on system 27.84 nws, with microcode 667, on LISP Machine Eleven: The system menu operation "Move Multiple" doesn't seem to win, at least not after setting up a screen with ZMACS, LISP, PEEK using SPLIT-SCREEN, then burying the LISP, and then doing EXAND, then doing MOVE MULTIPLE (the screen manager doesn't do its thing, leaving dead stuff all over the top of the underlying LISP listener). The edge I was trying to move was the top of the peek window.  Date: 31 May 1980 15:52-EDT From: Howard I. Cannon Subject: New feature To: Moon at MIT-AI cc: BUG-NWS at MIT-AI Date: 31 May 1980 02:15-EDT From: David A. Moon To: BUG-NWS at MIT-AI Re: New feature Question: should we make these top kludges work on new keybaords as well? Answer: Yes.  Moon@MIT-AI 05/31/80 03:32:45 To: (BUG NWS) at MIT-AI I left cadr6 compiling a bunch of files which needed to be recompiled because they had had flavor combined methods recompiled during the loading of 27.88 nws. Also recompiled a few other things that needed it: supdup, ehw, tscrol, menu, cometh, basstr, flavor, zymurg  Moon@MIT-AI 05/31/80 02:15:27 Re: New feature To: (BUG NWS) at MIT-AI I have made typing System followed by a letter find or create a window of the designated type. It is document in NWSOPR and by System Help. Also top-Esc = System and top-Return = End on old keyboards. Question: should we make these top kludges work on new keybaords as well?  Moon@MIT-AI 05/30/80 00:11:47 Re: Read, Print To: (BUG NWS) at MIT-AI When a world is built with the latest version of LMIO;READ, the definition of READ-FOR-TOP-LEVEL can be deleted from WINTST. In the meantime I have left it in there unchanged. Let's change the :PRINT operation to an object to :PRINT-SELF and change the PRINT function to send a :PRINT message to the stream if the stream handles it. Arguments should be the same as those to SI:PRINT-OBJECT? Or should just the object and the PRIN1/PRINC flag be passed in as args? It's about time we did this.  Moon@MIT-AI 05/29/80 21:50:02 To: (BUG NWS) at MIT-AI I changed (SELECT-MIXIN :SELECT) to return T instead of garbage. Frames depend on the result of the :SELECT method to a pane returning non-NIL in order for :MOUSE-SELECT to a pane to work. This is what was shafting me last night. If this was the wrong place to fix it somebody else please fix it.  Date: 29 May 1980 17:10-EDT From: Howard I. Cannon To: BUG-NWS at MIT-MC I made a fix to LTOP, so it should get recompikled before building the next world. Just a reminder.  MMcM@MIT-AI 05/29/80 16:20:53 To: (BUG NWS) at MIT-AI there should be an :activate-p init option similar to :expose-p  Moon@MIT-AI 05/29/80 03:06:05 To: (BUG NWS) at MIT-AI In the version of nws on system 27.87 nws, with microcode 667, on LISP Machine Six: I hate to say this, but "nearly everything in this world is broken". I'm going home. More specifically, something is wrong with selection and frames, evinced by mouse-select of a pane (from the system menu) returning NIL sometimes but working after I put debugging machinery in place, and errors in the error handler while trying to debug that (maybe the EH problem is that meta-Z is broken, except that when I just try it it works. But once it got wrong number of arguments to some internal function.) You should around with things in this world and see if you can figure out what the fuck I am talking about.  Date: 28 May 1980 08:39-EDT From: Howard I. Cannon To: MMCM at MIT-AI cc: BUG-NWS at MIT-AI Date: 27 May 1980 15:43-EDT From: Mike McMahon To: HIC at MIT-AI cc: BUG-NWS at MIT-AI HIC@MIT-AI 05/11/80 21:42:23 If the error message is very long, the window error handler can **MORE** trying to set itself up invisibly, causing it to just sit there and stare at you. I don't know what precisely the right fix is, but... I made it print the error message after it comes up. There might be other need for a mixin that defines a before daemon on more-exception that causes the window to be put on the screen the same way select does, by exposing all superiors. That's not a bad idea at all.  MMcM@MIT-AI 05/28/80 02:54:25 To: (BUG NWS) at MIT-AI In the version of NWS on system 27.86 nws, with microcode 667, on LISP Machine Six: INSPECT-PANE-WITH-TYPEOUT-COMBINED-MOUSE-SENSITIVE-ITEM-METHOD was not compiled in a proper environment, so that it calls the macro INSPECT-WINDOW-WITH-TYPEOUT-WRAPPER-MOUSE-SENSITIVE-ITEM-METHOD directly. Because of the marginal feature of being able to call a macro, this almost works, except that it does not pass out multiple values. The observed symptom is that items are not mouse sensitive in the bottom pane of the inspector. Recompiling INSPCT does indeed fix the problem. If it cannot be fixed easily, it should probably be detected by the combined method compiler to give a warning message.  MMcM@MIT-AI 05/28/80 02:36:10 To: (BUG NWS) at MIT-AI In the version of NWS on system 27.86 nws, with microcode 667, on LISP Machine Six: INSPECT-PANE-WITH-TYPEOUT-COMBINED-MOUSE-SENSITIVE-ITEM-METHOD was not compiled in a proper environment, so that it calls the macro INSPECT-WINDOW-WITH-TYPEOUT-WRAPPER-MOUSE-SENSITIVE-ITEM-METHOD directly. Because of the marginal feature of being able to call a macro, this almost works, except that it does not pass out multiple values. The observed symptom is that items are not mouse sensitive in the bottom pane of the inspector. Someone who is less tired should figure out how to fix this properly, it may only be an initialization problem.  SHIPMN@MIT-AI 05/28/80 00:06:40 To: (BUG NWS) at MIT-AI Bug in grinder for Inspect: Try Inspecting, for example, nzwei:*lisp-indent-offset-alist* The grinder barfs because there is a list beginning with "do" which doesn't conform to the standard "do" format.  Date: 27 May 1980 15:43-EDT From: Mike McMahon To: HIC at MIT-AI cc: BUG-NWS at MIT-AI HIC@MIT-AI 05/11/80 21:42:23 If the error message is very long, the window error handler can **MORE** trying to set itself up invisibly, causing it to just sit there and stare at you. I don't know what precisely the right fix is, but... I made it print the error message after it comes up. There might be other need for a mixin that defines a before daemon on more-exception that causes the window to be put on the screen the same way select does, by exposing all superiors.  Moon@MIT-AI 05/27/80 03:05:18 Re: Paging in Zmacs ^XB command even when mini buffer not exposed To: (BUG NWS) at MIT-AI It appears to be a problem of gross working set size rather than any specific thing. Here are some of the major contributors to the paging: FORMAT, printing the prompt for c-X selection back and forth between the editor window and the echo area window printing the default buffer fooling with the mini buffer (deleting the interval, moving bp's, etc.) (at this point we are about 40% of the page faults through and start actually selecting the buffer). Paging associated with switching buffers, switching modes. Waking up the mouse process and paging it all back in. Doing a redefine-margins (unnecessarily) when the label string of the editor window is changed to the new buffer name  Moon@MIT-AI 05/27/80 02:47:58 To: (BUG NWS) at MIT-AI If you load MOON;PTRACE, esc thumb-up will turn on page tracing, and esc thumb-down will grind out the page trace into an editor buffer called PAGE TRACE. I don't recommend selecting the buffer until after the background process stops running.  Date: 26 May 1980 05:27-EDT From: Howard I. Cannon To: MOON at MIT-AI cc: BUG-NWS at MIT-AI Date: 26 May 1980 01:21-EDT From: David A. Moon To: BUG-NWS at MIT-AI I was documenting notification in NWSOPR and wrote the following sentence. an attempt to type out on a deexposed window of a kind which notifies rather than just waiting for you to expose it. There doesn't seem to be a value of deexposed-typeout-action to cause this to happen. Shouldn't there be? Isn't this what break-P in Supdup would like to do (as in ITS where it gets you back to DDT but if anything on the foreign machine types out will say "supdup wants the tty"). I'll leave it in the documentation for now. The only such thing was a kludge I implemented for the background window flavor. We could move that kludge to a mixin, which supdup could then include, or incorporate it directly at low-level. I like the mixin idea better.  MOON@MIT-AI 05/26/80 01:21:29 To: (BUG NWS) at MIT-AI I was documenting notification in NWSOPR and wrote the following sentence. an attempt to type out on a deexposed window of a kind which notifies rather than just waiting for you to expose it. There doesn't seem to be a value of deexposed-typeout-action to cause this to happen. Shouldn't there be? Isn't this what break-P in Supdup would like to do (as in ITS where it gets you back to DDT but if anything on the foreign machine types out will say "supdup wants the tty"). I'll leave it in the documentation for now.  HIC@MIT-AI 05/25/80 02:04:04 To: (BUG NWS) at MIT-AI I have hacked the error handler somewhat: It always rebinds the streams when EVAL'ing typed forms. In order to allow you to look at/fix STANDARD-INPUT, STANDARD-OUTPUT, or TERMINAL-IO, it binds the three special variables called OLD-x (fill in the x) which then replace the values of the three variables after the form is EVAL'ed. This should give more desirable behaviour in most cases. Please report anomalies. This change is only in the source.  MOON5@MIT-AI 05/24/80 17:35:22 To: (BUG NWS) at MIT-AI In system 27.84 nws, with microcode 667, on LISP Machine Six: The fix to my previous complaint about typeahead and escape commands doesn't work properly. If I type esc 0 F hic@ai return, part of the "hic@ai" goes into the io buffer of the lisp listener that was previously selected. It should do the diversion of input as soon as possible upon seeing the "F"; or perhaps even as soon as I type esc? Would that be wrong?  Date: 23 May 1980 01:31-EDT From: Mike McMahon To: MOON at MIT-AI cc: BUG-ZWEI at MIT-AI, BUG-NWS at MIT-AI Moon@MIT-AI 04/29/80 15:38:17 Re: Blown-out idea The save-kill-unmod menu you added to the editor recently should have a 4th column, window. Initially all buffers in exposed windows should be marked, but you can mark others. This can be used to select buffers and to set up 2-window displays. I'm not sure whether it is best to have 2 columns, for 2-window mode only, to have one column which allows multiple marks in it, to have a way of adding more columns by pushing at the right edge with the mouse, or what. But anyway there should be a quick way to set up multiple buffers in multiple windows through this kind of pointing mechanism. I have implemented a cross between split screen via menus and c-x 4, which seems to be closer to the right thing, as well as more general.  Date: 22 May 1980 23:20-EDT From: Howard I. Cannon To: Moon at MIT-AI cc: BUG-NWS at MIT-AI Date: 22 May 1980 21:34-EDT From: David A. Moon To: BUG-NWS at MIT-AI If I type ahead to a running program, then type esc 1 F, when the finger asks "please type space to flush this" it swallows a character of typeahead. Creating a window with esc should work like creating one with the mouse with respect to buffered typeahead. Fixed in the source.  Moon@MIT-AI 05/22/80 21:34:29 To: (BUG NWS) at MIT-AI If I type ahead to a running program, then type esc 1 F, when the finger asks "please type space to flush this" it swallows a character of typeahead. Creating a window with esc should work like creating one with the mouse with respect to buffered typeahead.  MOON@MIT-MC 05/22/80 17:03:39 Re: Spped of new window system To: GLS at MIT-AI CC: (BUG NWS) at MIT-MC Date: 22 MAY 1980 1331-EDT From: GLS at MIT-AI (Guy L. Steele, Jr.) Subject: Spped of new window system To: (BUG LISPM) at MIT-AI CC: GLS at MIT-AI In system 27.84 nws, with microcode 667, on LISP Machine Six: The new window system is absolutely wonderful now that I am used to it. The only thing that is annoying is its occasional slowness. The system often hesitates a shade too long when reacting to a mouse command. Also, creating a SUPDUP window takes about forever. I would recommend the following things to avoid minor but frequent annoyances. I don't know which of them are practical. (1) Have a pre-computed ED window and unconnected SUPDUP window in the cold load, which can be used when one is first needed. These plus the initial LISP listener are often all that one needs for a LISP Machine session, and if the cost of creating these would be eliminated it would be wonderful. This has been done for some time. (2) The system menu is used so often that maybe it and some of the associated software should be locked down in memory or micro-compiled. There is no micro compiler. Wiring down everything needed would use up too much main memory; it has to look at what else is on the screen. Anyway I doubt that you really use the system menu more than you use whatever you use to do the work you actually sat down at the machine to do in the first place. One of these days paging performance will be somewhat faster, when I get time. (3) 90% of all system menu references go through the SELECT choice, I find. I suggest that the default meaning of MOUSE-LEFT-CLICK be to go directly to the window selection menu. In the editor, this would not be available, much as single-right is unavailable for the system menu. Also, once on one machine there were escape commands for "go to an ED window", "go to a SUPDUP window", etc. that were super-great--those should be standard. There are going to be small-number-of-keystroke always-available commands for selecting particular types of windows. The mouse-left click already has a default meaning, which is select the window pointed at. (4) The menu for Save or Kill Buffers is really neat. However, it should be more clever. If I kill three buffers, I often have to type three carriage returns, because it doesn't realize that the default buffer after killing buffer j is about to be killed as buffer j+1. Keep up the good work!  MOON@MIT-MC 05/21/80 03:39:01 To: (BUG NWS) at MIT-AI MMcM@MIT-AI 05/20/80 16:51:30 To: (BUG NWS) at MIT-AI MMCM;DRIBBL is one that stands a chance of working. If it passes the style commitee, the old crock should probably be flushed. Looks mostly okay. One bug is that the :RUBOUT-HANDLER operation does not pass back multiple values, which is required for READ. The simplest thing would be to collect them with MULTIPLE-VALUE-LIST, and the hell with the consing. (PROG1 unfortunately does not pass back multiple values.)  MOON@MIT-MC 05/21/80 03:10:05 Re: Window Error Handler suggestions To: (BUG NWS) at MIT-MC I've been using it a lot lately and I have some suggestions for better useability. It should put some kind of arrow or marker on the current stack-frame in the stack-trace window. As it is it is very difficult to see where you are. This is compounded by the fact that when it first comes up the stack trace window is scrolled to the top rather than the bottom, thus the current frame is not even on the display at all. I clicked Edit on the menu expecting to edit the code displayed in the top pane. It asked me to mouse a function, which is OK, but the function name at the top of the top pane was not mouse-sensitive; it clearly should be since it is one of the most likely "arguments" to the Edit operation. When scrolling through the locals pane into the specials area it can get confusing; when the tag "Specials:" scrolls off the top, the label of this pane should change from "Locals:" to "Specials:". I often want to type non-window-EH commands at the window-EH; I don't see any reason why it couldn't have them work. In particular c-N and c-P are often more convenient for moving around stack frames than carefully positioning the mouse to the right region of the stack-trace pane and clicking. But other commands could be useful, too. [Stuff below here is of lesser importance. Stuff above I really care about.] Stack-frame "objects" display differently in the stack trace window and in the history window. Maybe this is all right, but it confused even me. I think it would be better if all panes with scroll bars always displayed them. It would be easier to tell what is going on. This is particularly true for the ones that don't have "more above" and "more below" markers. The flashy-scrolling regions should be changed not to display the fat arrow if they aren't going to do anything because you are already scrolled the maximum distance in that direction. I didn't make any of these improvements myself as I was trying to work on other things; but if you'd like me to contribute to the group effort I will.  MMcM@MIT-AI 05/20/80 16:51:30 To: (BUG NWS) at MIT-AI MMCM;DRIBBL is one that stands a chance of working. If it passes the style commitee, the old crock should probably be flushed.  Date: 20 May 1980 15:41-EDT From: Mike McMahon To: JLK at MIT-MC cc: BUG-NWS at MIT-AI JLK@MIT-MC 05/20/80 09:38:24 I put various kludges into the old window system supdp (gt-40 simulator, ARDS interpreter etc.) and am contemplating putting them into the NWS. You must only mean the ARDS interpreter, since the GT-40 simulator has been in the nws SUPDUP since the beginning. Is there a VT52 mode for TELNET somewhere? There is imlac simulation mode, since vt52's do not have the sail character set, region scrolling, insert/delete character, and overprinting. I really don't understand what you are proposing making this talk to either.  JLK@MIT-MC 05/20/80 09:38:24 To: (BUG NWS) at MIT-MC I put various kludges into the old window system supdp (gt-40 simulator, ARDS interpreter etc.) and am contemplating putting them into the NWS. However I have mixed feelings about installing it in SUPDUP rather than having a separate file of kludges. On one hand it does not get in the way currently and its nice to have it in one file in case people make changes to the system affecting it (and its nice for those of us that use it to have it in the default environment). On the other hand I find it a bit distasteful to have all these gross kludges thrown in (albeit useful) -- not that SUPDUP as a protocol is all that clean anyway, but...Something which forces the issue a bit more is a proposed TEK simluator which has to interpret ordinary control chars (unlike the two protocols above which are only driven by %TD codes). Is there a VT52 mode for TELNET somewhere? Maybe the idea of protocol simulation should be generalized somehow and there should be a command in SUPDUP/TELNET with appropriate wholine indicators to say what kind of terminal you claim to be simluating. In the long run we should adopt a better protocol for use internally and have various transducers from external protocols to this internal one (eventually this may become an external one as well). We should have a look at one developed by BEE and JEKULP which sounds pretty reasonable to me, although I haven't seen the details.  Date: 19 May 1980 22:52-EDT From: Mike McMahon To: MOON at MIT-AI cc: BUG-NWS at MIT-AI Moon@MIT-AI 05/17/80 21:11:03 Typing meta-. and clicking the left mouse button broke. The blinkers do the right thing but it selects the top window (to the window system but apparently not to zwei) rather than editing the definition of the pointed-to function. Are you sure it was lit up? What you describe is what happens when you click on something random, to allow you to move text from the top window to the mini-buffer. It always seems to work right for me when i point at a function name.  MOON@MIT-MC 05/19/80 19:54:00 To: MMCM at MIT-AI CC: (BUG NWS) at MIT-AI Date: 19 May 1980 16:54-EDT From: Mike McMahon To: MOON at MIT-AI cc: BUG-NWS at MIT-AI Moon@MIT-AI 05/18/80 02:03:25 If I telnet to XX, log in, hack, and type KK, it gets "3 illegal packet opcode" and furthermore typing c-Z does the same thing and hitting call echoes as . Well, is tops-20 supposed to send an eof or something? No, Telnet is supposed to say connection closed and ask for a host.  Date: 19 May 1980 16:54-EDT From: Mike McMahon To: MOON at MIT-AI cc: BUG-NWS at MIT-AI Moon@MIT-AI 05/18/80 02:03:25 If I telnet to XX, log in, hack, and type KK, it gets "3 illegal packet opcode" and furthermore typing c-Z does the same thing and hitting call echoes as . Well, is tops-20 supposed to send an eof or something?  TK@MIT-AI 05/19/80 10:45:37 To: (BUG NWS) at MIT-AI in system 28.82 on cadr-7: do a X set font bigfnt and it bombs with a rectangle out of bounds.  Date: 18 May 1980 22:45-EDT From: Henry I. Collins To: JERRYB at MIT-MC cc: BUG-NWS at MIT-MC We would appreciate it if you would not make modifications to system new window system code without first consulting us. If we are to present a consistant system to the user, it is necessary for there to be a "taste" committee. Besides, in this case we have decided to implement the features that you implemented in a different fashion. We much prefer receiving suggestions, which we will act upon. --Howard  Date: 18 May 1980 22:36-EDT From: Henry I. Collins To: Moon at MIT-AI cc: BUG-NWS at MIT-AI Date: 17 May 1980 20:36-EDT From: David A. Moon To: BUG-NWS at MIT-AI In 27.82 nws, all inferiors of a frame must have a :ALIAS-FOR-SELECTED-WINDOWS method, which is not supplied as part of all windows (menus for instance). Is it the intention that all inferiors of a frame are *required* to include PANE-MIXIN now? Um, this appears to be a bug. I guess the trivial :ALIAS-FOR-SELECTED-WINDOWS should be mvoed to SHEET. We could also make PANE-MIXIN required, if you think that's better.  Date: 18 May 1980 22:33-EDT From: Henry I. Collins To: rg at MIT-AI cc: BUG-NWS at MIT-AI Date: 17 May 1980 22:36-EDT From: Richard Greenblatt To: BUG-NWS at MIT-AI system 27.82 nws microcode 666 CADR 4 While running the inspector, grindef tried to throw to GRIND-DOESNT-FIT-CATCH, and there was no catch for that. I was mousing the SHEET-INFERIORs instance variable of the inspect-frame. I took a couple of ESC-Qs which may help someone track this down. This is a known bug, and it is due to trying to print an atom that doesn't fit on one line. I guess something should be done about it, like gridn should be rewritten...  Moon@MIT-AI 05/18/80 02:03:25 To: (BUG NWS) at MIT-AI In the version of nws on system 27.82 nws, with microcode 666, on LISP Machine Six: If I telnet to XX, log in, hack, and type KK, it gets "3 illegal packet opcode" and furthermore typing c-Z does the same thing and hitting call echoes as .  Moon@MIT-AI 05/18/80 01:47:31 To: (BUG NWS) at MIT-AI The machine crashes if you do (ed) from a typeout window. It turns out what is going on is that the ed function launches the zmacs-windows process then returns; since the typeout window is auto-exposing it tries to reexpose itself to type a "T", however it gets into an infinite recursion, probably because as soon as it unlocks after exposing itself the zmacs windows process comes in and deexposes it again. I don't really completely understand who's deexposing it again (i.e. why it tries and tries and tries but doesn't manage to clear output-hold, even though the :expose message returns and the :expose-for-typeout method tries to type out (home up actually).) When you get the pdl overflow error you run into the usual problem that the error handler hasn't been improved to handle pdl overflows yet, even though the basic microcode mechanisms were put in long ago. Not that it would work anyway since it would try to type out on the typeout window and lose the same way. Anyway I "fixed" this by putting in a kludge; ED now finishes by doing (TV:AWAIT-WINDOW-EXPOSURE) which waits for the window to be exposed if its DEEXPOSED-TYPEOUT-ACTION is not :NORMAL. Unless someone can think of a better solution, this function should be called by the other similar functions.  Moon@MIT-AI 05/18/80 00:26:59 Re: Canine Bestiality To: (BUG NWS) at MIT-AI I lose my ass again (in 27.82 nws) doing eh of a dead process and doing describe. It should rebind the damned streams!!!!!  rg@MIT-AI 05/17/80 22:36:25 To: (BUG NWS) at MIT-AI system 27.82 nws microcode 666 CADR 4 While running the inspector, grindef tried to throw to GRIND-DOESNT-FIT-CATCH, and there was no catch for that. I was mousing the SHEET-INFERIORs instance variable of the inspect-frame. I took a couple of ESC-Qs which may help someone track this down.  Moon@MIT-AI 05/17/80 22:03:19 Re: Yet another cause of deadlocks To: (BUG NWS) at MIT-AI I changed the :MOUSE-BUTTONS methods of KBD-MOUSE-BUTTONS-MIXIN and BASIC-MOUSE-SENSITIVE-ITEMS not to send the :SELECT message directly, as this can deexpose the window that mouse is in (e.g. if it is a typeout window) which will wait in the mouse process for the mouse to leave that window. There may be other instances of this same bug.  Moon@MIT-AI 05/17/80 21:25:46 Re: Previous message re-sent To: (BUG NWS) at MIT-AI In the version of nws on system 27.82 nws, with microcode 666, on LISP Machine Six: (DEFMETHOD (PANE-MIXIN :MOUSE-SELECT) (&REST ARGS) "When selecting a pane with the mouse, pass the selection request to the frame." (LEXPR-FUNCALL SUPERIOR ':MOUSE-SELECT ARGS)) This method is a joke. It never selects the particular pane which was clicked on, but instead selects the SELECTED-PANE of the frame or beeps if there isn't one, which there typically isn't when you do this. I see, this isn't as dumb as it seemed at first glance. But I am still being shafted by the fact that you can't point at a deexposed inferior of a frame and get it selected.  Moon@MIT-AI 05/17/80 21:23:25 To: (BUG NWS) at MIT-AI In the version of nws on system 27.82 nws, with microcode 666, on LISP Machine Six: (DEFMETHOD (PANE-MIXIN :MOUSE-SELECT) (&REST ARGS) "When selecting a pane with the mouse, pass the selection request to the frame." (LEXPR-FUNCALL SUPERIOR ':MOUSE-SELECT ARGS)) This method is a joke. It never selects the particular pane which was clicked on, but instead selects the SELECT-PANE of the frame or beeps if there isn't one, which there typically isn't when you do this.  Moon@MIT-AI 05/17/80 21:11:03 To: (BUG NWS) at MIT-AI In the version of nws on system 27.82 nws, with microcode 666, on LISP Machine Six: Typing meta-. and clicking the left mouse button broke. The blinkers do the right thing but it selects the top window (to the window system but apparently not to zwei) rather than editing the definition of the pointed-to function.  Moon@MIT-AI 05/17/80 20:42:43 To: (BUG NWS) at MIT-AI Why does PANE-MIXIN gratuitously include DONT-SELECT-WITH-MOUSE-MIXIN? What if I want to select it with the mouse? I'm sure that in most cases whether or not you want to select it with the mouse has nothing to do with whether it is in a frame.  Moon@MIT-AI 05/17/80 20:36:57 To: (BUG NWS) at MIT-AI In 27.82 nws, all inferiors of a frame must have a :ALIAS-FOR-SELECTED-WINDOWS method, which is not supplied as part of all windows (menus for instance). Is it the intention that all inferiors of a frame are *required* to include PANE-MIXIN now?  MMcM@MIT-AI 05/17/80 15:25:07 To: (BUG NWS) at MIT-AI There is a 28.82 nws on CADR6. I have found and fixed a number of bugs in the recent changes and this system seems to work alright.  MMCM@MIT-AI 05/16/80 23:30:00 Re: Vandalism to KBD-ESC To: (BUG NWS) at MIT-AI I have moves the latest version of BASSTR to BASSTR JERRYB and removed the corresponding changes from the installed version, since after some consultation they were deemed misguided. Something along these lines should be implemented in a more reasonable fashion, as previously discussed.  Date: 16 May 1980 22:51-EDT From: Mike McMahon To: JLK at MIT-MC cc: BUG-NWS at MIT-AI Date: 15 MAY 1980 1828-EDT From: JLK at MIT-AI (John L. Kulp) In the window error handler are EDIT, SET ARG, or SEARCH supposed to work? They all seem to in the latest system.  MOON@MIT-MC 05/16/80 21:30:55 To: Henry at MIT-AI CC: (BUG NWS) at MIT-MC Date: 16 MAY 1980 0259-EDT From: Henry at MIT-AI (Henry Lieberman) To: (BUG LISPM) at MIT-AI In system 27.77 NWS, with microcode 663, on LISP Machine Eight: Systems having the NWS should have a feature in (STATUS FEATURES) so that programs can tell whether they've got the NWS. Or is there something else to test NEW-WINDOW-SYSTEM-P? This is somewhat pointless, since soon it won't be new anymore. You can use (pkg-find-package "tv" ':find) which will return nil if there is no TV package.  Date: 16 May 1980 13:17-EDT From: Mike McMahon To: JLK at MIT-MC cc: BUG-NWS at MIT-AI JLK@MIT-AI 05/16/80 00:28:55 The SUPDUP gt40 kludge dies when it calls TV-DEFINE-BLINKER. This used to work in the NWS so I guess something has changed. Please specify what system this was on, so that we have some chance of knowing whether the bug has been fixed or not. Also, I like the way editor and peek windows show up in the window select menu -- it would be nice if SUPDUP and LISP windows appeared in the same style. It already says what host the supdup is talking to, and there is nothing corresponding to that for LISP listeners, so i cannot figure out what you mean.  jerryb@MIT-AI 05/16/80 13:01:02 To: (BUG NWS) at MIT-AI In the version of nws on system 27.79 nws, with microcode 663, on LISP Machine Four: In the scroll bar (on the left) of a peek window, if the cursor is to the extreme top or bottom of the window then clicking either mouse left or right gives a "the argument ARRAY was NIL which is not an array" error. Also Q to a peek window doesn't kill it, it just deexposes it. Peek windows should have a P command which bury them and let the screen manager select another window. Sending a :BURY to the interaction pane of an inspect frame seems to send things into an infinite loop. I wanted to bury the whole frame, what is the right way to do this?  JLK@MIT-AI 05/16/80 00:28:55 To: (BUG NWS) at MIT-AI The SUPDUP gt40 kludge dies when it calls TV-DEFINE-BLINKER. This used to work in the NWS so I guess something has changed. Also, I like the way editor and peek windows show up in the window select menu -- it would be nice if SUPDUP and LISP windows appeared in the same style.  Moon@MIT-AI 05/15/80 14:20:03 Re: Lack of ability to recompile world To: (BUG NWS) at MIT-AI If you load the latest LISPM2;NSTRUC before initiating compilation, the symptom should be removed by the kludge I have put in.  Date: 15 May 1980 10:11-EDT From: Henry I. Collins Subject: Screen management and autoexposing To: Moon at MIT-AI cc: BUG-NWS at MIT-AI I have fixed (in the source) the lossages that caused autoexposure not to happen if there was no screen-array (also, it wouldn't have worked right anyway, but I fixed that). So, now if SCREEN-MANAGE-DEQUEUE-ENTRY discovers that there is no screen-array, it will do an explicit :order-inferiors/:screen-manage-autoexpose-inferiors. Also, I have one thing to say regarding temporary area lossage: FUCK!!!! I started recompiling the whole world, but it obviously didn't win. I suspect that the whole world wants to be recompiled, to fix up all the compiled flavor methods. I believe I have tested all except this last change, so there sholdn't be too much broken. As I told MMCM, if people get desperate I can be reached at 201-444-9879 but don't call Saturday please (I know, no one will want to talk to me anyway, but...). --Howard  me@MIT-AI (Sent by ___041@MIT-AI) 05/15/80 04:51:43 To: (BUG NWS) at MIT-AI Your compilation didn't work. It reliably blows out with temporary area lossage in DEFSTRUCT while compiling SHWARM, because the property list of WHO-LINE-ITEM has a bad DEFSTRUCT-INITS property that is trying to be :included.  Moon@MIT-AI 05/15/80 03:17:05 To: (BUG NWS) at MIT-AI In SCREEN-MANAGE-DEQUEUE-ENTRY there is a SHEET-FORCE-ACCESS. This screws me because I have a deexposed frame without a bit-save array. I deexpose one of its inferiors and expect auto-exposure to cause other inferiors to get exposed, but this does not happen because the SHEET-FORCE-ACCESS punts, preventing the :SCREEN-MANAGE message from ever being sent. And the :SCREEN-MANAGE-AUTOEXPOSE-INFERIORS message is not sent by SCREEN-MANAGE-DEQUEUE-ENTRY itself, but by (:METHOD SHEET :SCREEN-MANAGE), which never gets called. I won't fix this myself since I don't really understand the issues. But is causing me trouble. I'll put a kludge into the drawing program for the moment.  Date: 14 May 1980 02:02-EDT From: Henry I. Collins Subject: Fixes! To: BUG-NWS at MIT-MC I just made about 20 sundry fixes to the window system. Among them are: A) You can now say things like (0.33s0 :LINES ) to round off to a multiple of lines relative to that pane. This is especially useful for :HORIZONTAL or :VERTICAL constraints. B) **IMPORTANT** The variable LEVEL-COUNT has been flushed from sheets. I removed all references to it in the code, but was going to leave it around in the defflavor for a while until we could reassemble all the code since the instance variables are ordered. Instead, I noticed that it was the last sheet instance variable so I flushed it. WILL THIS SCREW ANYTHING? LET ME KNOW BEFORE WE LOSE BIG. C) A SHEET-DONT-BLINK-BLINKERS flag has been added. Blinkers will not be looked at for the sheet that has this flag set to 1, not will any of its inferiors be looked at. This is really for my super-winning esoteric hacks... That's about it for things of general interest. Don't report any bugs in the fixes -- fix them... --Howard  Date: 14 May 1980 00:57-EDT From: Henry I. Collins Subject: to mega therion To: MMcM at MIT-AI cc: BUG-NWS at MIT-AI Date: 13 May 1980 22:44-EDT From: Mike McMahon To: BUG-NWS at MIT-AI Re: to mega therion UCADR 666 fixes clipping of triangles with negative coordinates I refuse to run any microcode with that version number. I bet you have connections to Margaret Mead and the cult of Isis and Osouris. A disgruntled user  MMcM@MIT-AI 05/13/80 22:44:10 Re: to mega therion To: (BUG NWS) at MIT-AI UCADR 666 fixes clipping of triangles with negative coordinates  MMcM@MIT-AI 05/13/80 17:30:50 To: (BUG NWS) at MIT-AI In newer worlds, "ZWEI" will be a refname for the NZWEI package. If you have code in your init file for NZWEI which is an exact copy in all other regards of your ZWEI code, it can be flushed. If you have separate code for each, should should make sure only the NZWEI code goes off in the nws.  MMcM@MIT-AI 05/13/80 17:12:57 To: (BUG NWS) at MIT-AI since select-mixin defines a :process message, shouldn't the who line send that message to selected-window rather than relying on selected-io-buffer, which isn't correct until the window first does a tyi?  HIC@MIT-AI 05/13/80 00:45:54 To: (BUG NWS) at MIT-AI I'd appreciate people taking a glance at LMWIND;FRAME > and letting me know if I'm on the right track. MOON: Don't forget to implement request type .defmethod in the format we discussed.  HIC@MIT-AI 05/11/80 21:42:23 To: (BUG NWS) at MIT-AI If the error message is very long, the window error handler can **MORE** trying to set itself up invisibly, causing it to just sit there and stare at you. I don't know what precisely the right fix is, but...  ALAN@MIT-AI 05/11/80 00:27:35 To: (BUG NWS) at MIT-AI In move multiple, you now hold down the button for a while to pick up the corners/edges, and then you release the button, move around freely, and click again to finish. This is more compatible with other things.  ALAN@MIT-AI 05/09/80 16:43:32 To: (BUG NWS) at MIT-AI In the version of NWS on system 27.79 nws, with microcode 661, on LISP Machine Six: Using move-multiple: if I try to move an edge that is already as far down as it can go just a little further, then it looks like I get stuck in a loop calling tv-beep (or some other screen flasher). The edge that I have picked up is still attached to the mouse, which is still being tracked between flashes. This only seems to happen when the edge starts all the way to the bottom of the screen. If I try to move an edge that is further up, off the bottom of the screen, then I am flashed at ONCE and am put back in the window editor.  MMCM@MIT-AI 05/08/80 23:10:27 To: (BUG NWS) at MIT-AI somehow the frame system should avoid creating panes initially the full size of the screen.  Date: 7 May 1980 22:56-EDT From: Mike McMahon To: MOON at MIT-MC cc: BUG-NWS at MIT-AI MOON@MIT-MC 05/07/80 22:48:11 MMcM@MIT-AI 05/06/80 04:01:48 ANY-TYI-MIXIN should not have SHEET as an included flavor, which it now gets via STREAM-MIXIN. Perhaps it should be split up into two flavors, one just defining the new methods and having :ANY-TYI has a required message, and the other then defining that as it does now and including STREAM-MIXIN. Comments? I don't understand the business about SHEET, or why it should matter whether or not it is included. For that matter I also don't see how the other methods in ANY-TYI-MIXIN (e.g. :LIST-TYI) would ever be the right thing. So it sounds like you're proposing to split it into one mixin that no one would ever use and another that should probably replace STREAM-MIXIN in all windows. I have already implemented the change i mentioned, since it was needed to make ZTOP work. I made LIST-TYI-MIXIN with :REQUIRED-METHODS :ANY-TYI which was all the other methods there, and ANY-TYI-MIXIN dependent on it with :ANY-TYI (STREAM-MIXIN :TYI), and including STREAM-MIXIN. The problem was that i had a stream which was not a sheet and wanted the same filtering, it already had it's own :ANY-TYI (it even has an IO-BUFFER).  MOON@MIT-MC 05/07/80 22:48:11 To: (BUG NWS) at MIT-MC MMcM@MIT-AI 05/06/80 04:01:48 To: (BUG NWS) at MIT-AI ANY-TYI-MIXIN should not have SHEET as an included flavor, which it now gets via STREAM-MIXIN. Perhaps it should be split up into two flavors, one just defining the new methods and having :ANY-TYI has a required message, and the other then defining that as it does now and including STREAM-MIXIN. Comments? I don't understand the business about SHEET, or why it should matter whether or not it is included. For that matter I also don't see how the other methods in ANY-TYI-MIXIN (e.g. :LIST-TYI) would ever be the right thing. So it sounds like you're proposing to split it into one mixin that no one would ever use and another that should probably replace STREAM-MIXIN in all windows.  Date: 7 May 1980 20:19-EDT From: Henry I. Collins To: HIC at MIT-MC cc: BUG-NWS at MIT-MC Date: 7 May 1980 16:01-EDT From: Henry I. Collins To: BUG-NWS Trying to create a PEEK in a split screen can hang in "Activate" due to some timing screw/deadly-embrace. Fixed.  Date: 7 May 1980 16:01-EDT From: Henry I. Collins To: BUG-NWS at MIT-MC Trying to create a PEEK in a split screen can hang in "Activate" due to some timing screw/deadly-embrace. Set Arg in error handler menu just beeped at me. Isthere somethng I should know?  Date: 7 May 1980 15:59-EDT From: Henry I. Collins Subject: ANY-TYI-MIXIN To: MMcM at MIT-AI cc: BUG-NWS at MIT-AI As long as you don't break anything (that goes without saying), any such changes are fine with me. Generally, I feel that you are welcome to rearrange flavors as long as the interfaces look the same to the user.  Moon@MIT-AI 05/07/80 03:28:08 Re: Who line heuristics To: (BUG NWS) at MIT-AI What do you think of making WINDOW-CALL put the CURRENT-PROCESS into the window's io-buffer (which it must have since it's being selected?) This is reasonable since the WINDOW-CALL is always done by the process that's going to use the window, whereas it would not be reasonable to have the :SELECT message store CURRENT-PROCESS into the io-buffer. Above is not in fact true, since you can send a :SELECT to a frame, which will not allow itself to be put into SELECTED-WINDOW and does not have an i/o buffer, and it's entirely reasonable to use WINDOW-CALL on a frame. Suppose we recycle the argument to :SELECT for this? An idea I like better is to have WINDOW-CALL, after sending the :SELECT, put current-process into the selected io-buffer (if non-nil). An example of where this would be useful is esc-F, where you can't watch it trying to open the network connection in the who-line, because the who-line only gets set up when it gets to the end and asks for input. This is different from the "usual case " because for each esc F there is a new process behind the window. A completely different approach to the problem would be to have a new scheme whereby when a process allocates a resource (the esc-F window isn't actually a resource, but it should be), it tells the newly-allocated window about itself. Perhaps STREAM-MIXIN should support :SET-PROCESS as well as :PROCESS. Then the only difference with PROCESS-MIXIN is what it implies about killing.  Moon@MIT-AI 05/06/80 23:52:11 To: (BUG NWS) at MIT-AI If you put something with KLUDGE-INFERIOR-MIXIN under a frame, when it is deexposed an infinite recursion appears. The reason is that a :BEFORE :DEEXPOSE method sends a :SELECT, which may need to deexpose the kludge inferior, which isn't deexposed yet. If this was fixed it wouldn't work anyway since its deciding whether the frame is selected doesn't know to look and see if the frame has an inferior selected pane. Indeed, the interaction of selection with frames and window-hierarchy in general needs to be designed.  MMcM@MIT-AI 05/06/80 21:55:52 To: (BUG NWS) at MIT-AI [Process foo wants the TTY] does not make sure the window gets activated any more, making it impossible to access sometimes.  MMcM@MIT-AI 05/06/80 04:01:48 To: (BUG NWS) at MIT-AI ANY-TYI-MIXIN should not have SHEET as an included flavor, which it now gets via STREAM-MIXIN. Perhaps it should be split up into two flavors, one just defining the new methods and having :ANY-TYI has a required message, and the other then defining that as it does now and including STREAM-MIXIN. Comments?  Date: 5 May 1980 14:36-EDT From: Henry I. Collins To: MMCM at MIT-AI cc: BUG-NWS at MIT-AI Date: 5 May 1980 13:01-EDT From: Mike McMahon To: HIC at MIT-AI cc: BUG-NWS at MIT-AI HIC@MIT-AI 05/05/80 10:37:20 ... I have also made it pass down TURN-ON-BLINKERS. I am not sure that is right. Alright, I'll change it back then until we decide.  Date: 5 May 1980 13:01-EDT From: Mike McMahon To: HIC at MIT-AI cc: BUG-NWS at MIT-AI HIC@MIT-AI 05/05/80 10:37:20 ... I have also made it pass down TURN-ON-BLINKERS. I am not sure that is right.  Date: 5 May 1980 11:22-EDT From: Henry I. Collins To: BUG-NWS at MIT-MC cc: TK at MIT-MC I have converted the window error handler to using the new preemptable read stuff, and it seems to work fine. TK: spurious typeahead will no longer cause the mouse not to work.  HIC@MIT-AI 05/05/80 10:37:20 To: (BUG NWS) at MIT-AI I have made :EXPOSE let the inferiors default the bit action (assuming that specifing :CLEAN at one level does not imply all levels is probably reasonable). I have also made it pass down TURN-ON-BLINKERS.  Date: 5 May 1980 10:14-EDT From: Henry I. Collins To: Moon at MIT-AI cc: BUG-NWS at MIT-AI Date: 5 May 1980 02:35-EDT From: David A. Moon To: BUG-NWS at MIT-AI Every entry in the system menu has a  (right arrow) in it. Any reason not to flush them? Flush them!!!  Moon@MIT-AI 05/05/80 02:35:42 To: (BUG NWS) at MIT-AI Every entry in the system menu has a  (right arrow) in it. Any reason not to flush them?  Moon@MIT-AI 05/05/80 01:55:43 Re: Bug in (:METHOD SHEET :EXPOSE) To: (BUG NWS) at MIT-AI When you expose a frame with no bit save array, all its exposed-inferiors get exposed with a bit-action of :CLEAN (rather than NIL meaning to default based on whether or not they have bit arrays themselves). This is because the method doesn't keep its argument BITS-ACTION and the internal value separate.  Date: 5 May 1980 00:54-EDT From: Mike McMahon To: HIC at MIT-AI cc: BUG-NWS at MIT-AI HIC@MIT-AI 04/27/80 01:35:06 In two places in NZWEI;SCREEN > the function TV:WINDOW-WITH-TYPEOUT-MIXIN-TYPEOUT-WINDOW is referenced by name. Unfortuantly, the name of that flavor changed. I fixed this in the source, but am puzzled as to why this completely unmodular thing is being done as opposed to something more reasonable. Can someone enlighten me? Well, that's the way the names of OUTSIDE-ACCESSIBLE-INSTANCE-VARIABLE accessor macros get created.  MOON@MIT-AI 05/04/80 03:56:24 Re: Flavor compilation at load time To: (BUG NWS) at MIT-AI In the latest FLAVOR (which is not actually present in the dumped-out 27.70 nws) there is a new variable, SI:*FLAVOR-COMPILATIONS*, which is a list of all the methods that have been generated and compiled (to core not to qfasl file) by the flavor system. You can reset it to NIL any time you like. Using this I found that 74 methods were compiled during loading of 27.70 nws. I have determined the causes of all of these and am about to start a recompilation which if it completes without error should cause the next world loaded not to have any flavor compilation during its loading (possibly there may still be some when you first create certain obscure windows, although almost all windows used are now instantiated some time during loading, e.g. via resources). If you're interested until I next clean up my directory the file AI:MOON;.FLAV. (COMP) will have the data.  Moon@MIT-AI 05/04/80 02:21:13 Re: Changes to menu system To: (BUG NWS) at MIT-AI NMENU has been replaced by MENU, which has extensive changes by Hic and myself. This is operational in 27.70 nws.  HIC@MIT-AI 05/03/80 11:35:12 To: (BUG NWS) at MIT-AI :EXPOSE-FOR-TYPEOUT is now on the default init plist for the DEEXPOSED-TYPEOUT-ACTION of BASIC-TYPEOUT-WINDOW.  HIC@MIT-AI 05/03/80 03:17:35 To: (BUG NWS) at MIT-AI I have defined :PANE-SIZE on ESSENTIAL-WINDOW which should do the right thing when a pane wants to remain the same size in a frame. Therefore :ASK :PANE-SIZE should replace all occurances of :ASK :PANE-WIDTH and :ASK :PANE-HEIGHT. This has not been tested, so...  Moon@MIT-AI 05/03/80 02:34:18 Re: Lack of ability to warm-boot To: (BUG NWS) at MIT-AI I fixed the particular symptom by setting TV:MOUSE-WINDOW to NIL in LISP-REINITIALIZE. It would hang waiting for the mouse to get out of a sheet so that it could de-expose it so that it could bring up the top window, at a time when the mouse process wasn't running yet. A less ad hoc fix would be appreciated. It shouldn't start hacking windows before it has the various processes going, including enough things initialized so you can hit esc call when you lose your ass. Unfortunately a plethora of bugs in the console program prevented me from getting a stack trace to find out where this de-expose that got hung was happening.  Moon@MIT-AI 05/03/80 01:00:14 Re: Lossage! To: (BUG NWS) at MIT-AI Don't fail to document that typeout windows don't work unless when you create them you include the init option: ':DEEXPOSED-TYPEOUT-ACTION '(:EXPOSE-FOR-TYPEOUT)  Moon@MIT-AI 05/02/80 16:48:06 To: (BUG NWS) at MIT-AI In system 27.65 NWS, with microcode 661, on LISP Machine Six: Two bugs and some suggestions: (1) In the inspector, if I am inspecting an array which is a named-structure and has an array leader, there is no obvious (or even non-obvious!) way to inspect the array part of it. There should be a menu command to re-inspect the current object at a lower level of abstraction. Also probably inspecting a named structure that is an array leader should show the array too. It would also be nice if there was a command somewhere to make numbers be printed in "~:@C" format (maybe by pointing at a menu command then at a specific number.) In the inspector, could the menu be permanent rather than pop-up? It wouldn't take much space and would make it easier to guess how to do things; I like the way it is in the EHW better. Also the inspector should have a few keyboard commands, and random typing at the keyboard should go to a read-eval-print loop in the interaction pane (as in the EHW). (2) The very first time I start up the editor, in a freshly cold-booted world, if I type ahead c-C c-F after typing (ed), the c-C goes into the io-buffer of the Lisp listener, but the c-F goes into the io-buffer of the editor. Someone also swallows the c-C because it is the last character in the lisp listener's io-buffer but said buffer is empty. I don't think anything beeped at me as it usually does when you type a control character at a Lisp listener. This effect does not occur upon subsequent startups of the editor; it does happen even if I wait a fairly long time between typing the close parenthesis and typing the c-C.  Moon@MIT-AI 05/01/80 17:05:08 Re: Incompatible change to MENU-CHOOSE To: (BUG NWS) at MIT-AI I moved the second (optional) argument [which no one uses] to be the third argument, and added a new optional argument as the second argument which is the label to appear above the menu. It defaults to no label.  HIC@MIT-AI 05/01/80 09:35:04 To: (BUG NWS) at MIT-AI 10118 pages is the size of the world now without compression...saved about 2000 pages...not bad...  HIC@MIT-AI 05/01/80 06:33:00 Re: Who line updating problem To: (BUG NWS) at MIT-AI I have fixed the bug that was causing the marjority of the lossage. Of course, since the whole thing is only heuristic it can't be 100% garunteed, but it tries...  HIC@MIT-AI 05/01/80 06:08:55 To: (BUG NWS) at MIT-AI I find myself typing (Inspect ) P in the editor alot. It would be nice if there was a command to do that (like Meta-X Inspect, or perhaps just a single character which would do (inspect) with no args).  Moon@MIT-AI 04/30/80 15:01:09 To: (BUG NWS) at MIT-AI I added the following methods to BASIC-CONSTRAINT-FRAME. It didn't seem worth making them a separate mixin. They go along with the :GET-PANE method that was already there. These methods were in QUEST before under different names, but I find I need them for other things, too. :PANE-NAME - given a pane returns its name (opposite of :GET-PANE) :SEND-PANE pane-name message &rest args - find pane and sent it a message :SEND-ALL-PANES message &rest args - broadcast message to all panes :SEND-ALL-EXPOSED-PANES message &rest args - broadcast message to all panes in current configuration  Date: 30 April 1980 06:48-EDT From: Howard I. Cannon To: Moon at MIT-AI cc: BUG-NWS at MIT-AI Date: 29 April 1980 10:02-EDT From: David A. Moon To: BUG-NWS at MIT-AI In the version of nws on system 27.46 NWS, with microcode 661, on LISP Machine Six: Could the RESOURCE macro be renamed to WITH-RESOURCE? I have DEFF'ed this to be the case. We should change code as we remember.  Date: 30 April 1980 06:45-EDT From: Howard I. Cannon To: HIC at MIT-MC cc: BUG-NWS at MIT-MC Date: 30 April 1980 05:39-EDT From: Howard I. Cannon To: BUG-NWS I made temporary bit arrays not get created until they are needed, and I made windows create their bit-arrays the correct size right off the ------------^^^^ That should read "menus" bat (this took a minor kludge, but if you don't look too hard...). Anyway, the mini-buffer has a typeout window and assocated menu. Is this really right?  Date: 30 April 1980 05:39-EDT From: Howard I. Cannon To: BUG-NWS at MIT-MC I made temporary bit arrays not get created until they are needed, and I made windows create their bit-arrays the correct size right off the bat (this took a minor kludge, but if you don't look too hard...). Anyway, the mini-buffer has a typeout window and assocated menu. Is this really right?  HIC@MIT-AI 04/30/80 04:33:35 To: (BUG NWS) at MIT-AI The following blinker in the editor top level no longer follows all the time, and also leaves turds sometimes. I already fixed this once -- it's someone else's turn...  Moon@MIT-AI 04/29/80 15:59:58 To: (BUG NWS) at MIT-AI The :blinker-function init-option (for sheets) should be renamed to :blinker-flavor.  MOON@MIT-AI 04/29/80 11:30:14 To: (BUG NWS) at MIT-AI In the initial world there are 57. windows (I am not shitting you!) of which 13. have bit-save arrays. These are full-size except for 2, one of which is a little smaller and is obviously the editor, and one of which is a little bigger (1600 high instead of 1564) and belongs to BASIC-PEEK-1. There are also 16. rouchly screen-sized temporary bit arrays, as well as a bunch of smaller ones. Most of these temporary bit arrays are on obscure menus whose size is the size of their superior because they have never been used and their ITEM-LIST is unbound. Probably most of these menus will never be used in a typical session, and they should either not be created at all or they should get their temporary bit arrays only when they need them. In fact, temporary bit arrays should be a resource as far as I can see. Actually they need be several resources of different sizes or something like that. Another fix would be to make menus default to a more reasonable size when their item-list is unbound. I can't really tell where all these menus come from; 5 of them come from the typeout windows associated with the 5, count 'em, 5 (five) initial Zwei and Zmacs windows, and one comes from the inspector. The other 10 have the CPT screen as their superior.  MOON@MIT-AI 04/29/80 10:39:25 Re: Gross bloatage To: (BUG NWS) at MIT-AI Discoveries so far: The system menu's bit array is "full size" (that is, the size of a CPT monitor). Probably all bit arrays are this size (21K words). There seems to be a good deal of temporary list structure consed by the flavor system. I guess I could either put this in a temporary area or work on the GC. Some of the list space is occupied by temporary junk consed by the chaosnet for background requests and the file system for transactions. Structure space seems to be full of temporary strings made by filename parsing and by the flavor system, although I think its bulk is bit-save arrays. Relative proportions are about 272K in list space and 1000K in structure space. Also there are some flonums; they don't take up any significant space, I'm just amazed that there are any. I think there are about 30 bit-save arrays of full-size in the world, at 20K each this would account for half of working-storage area. Unfortunately I don't know the exact number because the machine crashed after I fixed a bug and the damned 27.46 nws cannot warm-boot (apparently all processes are flushed and nothing will talk to me although the blinkers blink and the time in who-line counts). [Well, said warm-boot lossage only happens when the editor typeout window is being used via a break-loop; maybe the initial startup process is arrested or something and therefore dies early in initialization? Can't look at it now. It's reproduceable.] Only 3 bit arrays are accounted for (2 on active windows and 1 loose on the resource [why?]). But there are a lot of deactivated windows.  Moon@MIT-AI 04/29/80 10:02:30 To: (BUG NWS) at MIT-AI In the version of nws on system 27.46 NWS, with microcode 661, on LISP Machine Six: Could the RESOURCE macro be renamed to WITH-RESOURCE?  MOON@MIT-AI 04/29/80 08:58:58 Re: Gross size of the load To: (BUG NWS) at MIT-AI Nearly half of it is in working-storage-area. I hope that most of that is inaccessible and will go away with the new GC. Macro-compiled-program is only 10% (320 K allocated, 296K used). The compiler has been run (in 27.46 NWS). I guess maybe I'll contribute to the group effort and crank up the old mark-sweep GC to see what fraction of the world is accessible. But I wonder who's doing all the gratuitous consing?  Date: 28 April 1980 22:53-EDT From: Howard I. Cannon Subject: Making things really work for multiple screens To: HIC at MIT-MC cc: BUG-NWS at MIT-MC I have finished hacking everything I can think of, so the system now "works" with multiple screens.  HIC@MIT-AI 04/28/80 21:10:54 To: MOON at MIT-AI CC: (BUG NWS) at MIT-AI There's a problem for fonts with FIT's that aren't 1 bit per pixel -- namely, everything that knows about the fit adds in raster-width, where what they really want to add in is (// raster-width bits-per-pixel). Therefore, what I want to do is to add a bits-per-pixel to the font. Unfortunatly, it's hard to add things to fonts. We should figure out (or write) some program that knows how to read a font qfasl, fix it up, and write it out, and find all of them on the directory. For now, perhaps I'll make it get bits-per-pixel from the sheet.  Date: 28 April 1980 06:40-EDT From: Howard I. Cannon To: BUG-NWS at MIT-AI The bug with deactivated windows had to do with frames. Deactivating a frame did not flush its panes from previously selected windows. This has been fixed, and should remind us all that selection is totally fucked. Background window streams will not be lisp-listener-p, fixing the bug where they would get selected by . Background windows will try to go away when the process they belong to terminates. I hope they try hard enough.... Note that a new window system world WITHOUT compression is about 12450 blocks long, which barely fits in the standard 12750 sized partition on the t-80's...sigh...be careful, I have lost by smashing a band already on cadr6.  HIC@MIT-AI 04/28/80 05:35:26 To: (BUG NWS) at MIT-AI Deactivated windows no longer seem to get removed from the list of previously selected windows. There is some wierd bug with background streams and error handling where sometime you select the window that got created, and it says that the process wants the tty and goes and makes another window.  HIC@MIT-AI 04/27/80 01:35:06 To: (BUG NWS) at MIT-AI In two places in NZWEI;SCREEN > the function TV:WINDOW-WITH-TYPEOUT-MIXIN-TYPEOUT-WINDOW is referenced by name. Unfortuantly, the name of that flavor changed. I fixed this in the source, but am puzzled as to why this completely unmodular thing is being done as opposed to something more reasonable. Can someone enlighten me? --Howard  HIC@MIT-MC 04/26/80 16:03:01 Re: New mouse blinker scheme To: HIC at MIT-MC CC: (BUG NWS) at MIT-MC Get rid of MOUSE-BLINKER. Have a MOUSE-BLINKER-MIXIN which defines the offsets for the mouse-x-offset and mouse-y-offset, and probably flush these variables. Leave MOUSE-BLINKER around as the blinker which is currently tracking the mouse. (MOUSE-SET-BLINKER name &optional (x-off 0) (y-off 0)) is used to setup the current mouse blinker. Old-visibility will be the visibility of the current blinker. The name of the current blinker is remember in MOUSE-BLINKER-NAME, and the blinker itself in MOUSE-BLINKER. Names are :STANDARD, :RECTANGLE, most sheet forward the message up. Screens have a new instance variable called MOUSE-BLINKER-LIST which is a list of (mouse-blinker-name . blinker). There is a global registry of mouse blinker names and creation functions, so that new screens can run around and make all the appropriate blinkers. Mouse initialization should set the mouse blinker back to DEFAULT-SCREEN and :STANDARD, along with the standard character definition. A MOUSE-SET-BLINKER-DEFINITION (name xoff yoff visibility message &rest args-to-message) causes the named blinker to get redefined as specified, atomically, and also to have a MOUSE-SET-BLINKER done to it.  H@MIT-AI (Sent by H0@MIT-AI) 04/26/80 10:37:35 To: (BUG NWS) at MIT-AI NETWORK key in SUPDUP gets an error, supdup-keys table too short...  Date: 26 April 1980 00:54-EST From: Howard I. Cannon Subject: Making things really work for multiple screens To: BUG-NWS at MIT-MC I have done about 75% of the work necessary to make the user-level system stuff work on multiple screens. (Look at the first few functions in SYSMEN). This includes most of the system menu, and some of the screen editor. What remains to be done is: 1) Hack up trace via menus and split screen via menus to do the right thing 2) Make sure all the blinkers get on the right sheet at the right time in the right font. I'm sure there are bugs relating to this in the screen editor.  ALAN@MIT-MC 04/25/80 04:46:54 To: (BUG NWS) at MIT-MC Someone should fix the gt40-blinker in supdup...gets phase decalred speial (others too)  MMcM@MIT-AI (Sent by HIC@MIT-AI) 04/25/80 02:07:28 To: (BUG NWS) at MIT-AI i added the process menu to peek. standalone peeks don't seem to get a process, though i don't really know why. the mouse sensitive scrolling window that peek uses appears to prepare the sheet long before it decides where to put the hollow rectangular blinker, which makes the mouse blinker disappear for a long time while moving around inside a peek window.  HIC@MIT-MC 04/22/80 17:00:00 To: (BUG NWS) at MIT-MC A) The new flavor system puts automatic methods into the fasl file before the DEFFLAVOR1 due to the way that EVAL-WHEN works. This cause undefined "flavor" errors when loading. B) The lastest microcode: 1) Doesn't seem to draw triangles 2) Does not DISK-RESTORE (I haven't looked into this, but (DISK-RESTORE n) justs sort of sits there...  HIC@MIT-AI 04/21/80 23:54:16 Re: New microcode To: (BUG NWS) at MIT-AI New window system runs shitload better with new microcode. Not blindingly fast, but you can damn sure notice the difference!!  HIC@MIT-AI 04/21/80 21:55:14 Re: Margin regions To: (BUG NWS) at MIT-AI I rearranged the code a little and I think it works better: A) Instead of being a before demon, it is an after demon. This means that the standard mouse-moves code runs before the margin hacking stuff B) I flushed the wrapper and the *THROW This has the effect that when the mouse moves out of the window in to a margin region, the appropriate things will happen to the window (like blinkers getting turned off, etc...). This seems to have a better effect in both the error handler and the inspect stuff. Any reason not to leave it like this? --Howard  HIC@MIT-AI 04/21/80 16:09:29 Re: Process SEND wants the tty To: (BUG NWS) at MIT-AI Was due to (believe it or not!) a (TV:BEEP)! I changed it to funcall it's window with TV:BEEP and it won...sigh...  HIC@MIT-AI 04/21/80 15:40:21 Re: Editor top level To: (BUG NWS) at MIT-AI I found and fixed the bug whereby the blinker would not follow the cursor position. Also, it is pretty obnoxious to have it print ^@ everytime I type meta-< or M-> and then have it wait for me to type a character at it to flush. Can't something be done to make this whole can of worms less fishy?  H@MIT-AI 04/19/80 11:46:58 To: (BUG NWS) at MIT-AI In the screen editor, doing a move-multiple, if you get the following arrow blinker close to the left edge of the screen (maybe on an editor window), it gets a negative X value, and tries to do the infinite BITBLT. For a moment it looks like you've been blasted by a Klingon.  MMCM@MIT-AI 04/19/80 07:56:27 To: (BUG NWS) at MIT-AI There is a NNWS on band 2 of cadr-6, it is probably not useful for very much except compiling. i have fixed a large number of bugs, and recompiled all the changed files. unless other things are changed, the next step should be to attempt another load-it.  Date: 19 April 1980 01:36-EST From: Mike McMahon To: HENRY at MIT-AI cc: BUG-NWS at MIT-AI Date: 19 APR 1980 0130-EST From: Henry at MIT-AI (Henry Lieberman) How bout having streams take a PRINT message in addition to TYO, etc. Often I would like to have output streams that intercept things at the PRINT level, TYO's too late. This is on the list of pending changes for the new window system already; the :PRINT message has to be renamed to :PRINT-SELF before it can be implemented though.  mmcm@MIT-AI (Sent by ___013@MIT-AI) 04/18/80 04:23:02 To: (BUG NWS) at MIT-AI all files should be now compiled. none have been tested. brave soul can do load-it.  MMcM@MIT-AI 04/17/80 05:52:09 To: (BUG NWS) at MIT-AI There are still some callers of BLINKER-SET-FUNCTION in SCRED and SCROLL that need to be thought about.  HIC@MIT-MC 04/17/80 00:04:24 Re: Talk on Thursday, April 23rd, 3:00 to 5:00 in the playroom To: DAM at MIT-MC CC: (BUG NWS) at MIT-MC I will talk on "The New Window System for the Lisp Machine". Abstract: The Lisp Machine interacts with the user through a high-speed display. In order to manage the display effectivly, given many different paradigms and multi-processing, a large body of software, called the window system, exists. We have completely reimplemented the Lisp Machine window system, and I will give an overview of its basic philosophy, as well as some details for both users and programmers. ----- I'd like to get better publicity for this talk than the flavor talk, as I know that there are many people in the lab interested in hearing this. I'd like this to get on the calendar, as well as have a system message put up. I guess I can take care of this if necessary. Since I expect this talk to be well attended, perhaps I should arrange for 512A...do you do this, or will I have to go through some other channels in order to do this? Thanks, Howard  Date: 16 April 1980 17:38-EST From: Howard I. Cannon To: MOON at MIT-MC cc: BUG-NWS at MIT-MC Date: 04/16/80 16:22:19 From: MOON at MIT-MC To: (BUG NWS) MMcM@MIT-AI 04/15/80 17:20:11 To: (BUG NWS) at MIT-AI The recent changes to the rubout handler's maintence of the cursor position cause very strange results when there are errors in read. What it should do (in my opinion) is what GSB's ttyscan does, namely not re-echo the input, and when you hit rubout erase the error message and the last character of input. We probably need a sheet primitive to erase between two cursorposes (including intervening lines). I'll do this if no demurrers are filed. You're in charge...fine with me  MOON@MIT-MC 04/16/80 16:22:19 To: (BUG NWS) at MIT-MC MMcM@MIT-AI 04/15/80 17:20:11 To: (BUG NWS) at MIT-AI The recent changes to the rubout handler's maintence of the cursor position cause very strange results when there are errors in read. What it should do (in my opinion) is what GSB's ttyscan does, namely not re-echo the input, and when you hit rubout erase the error message and the last character of input. We probably need a sheet primitive to erase between two cursorposes (including intervening lines). I'll do this if no demurrers are filed.  MOON@MIT-MC 04/16/80 15:25:36 Re: Making CC work in the NWS To: (BUG NWS) at MIT-MC Hmm, there must be a misunderstanding here. I made cursorpos work but didn't do anything else because someone told me they had fixed it. But either they didn't or it broke. OK, I'll be in charge. It's probably calling kbd-char-available some place.  Date: 16 April 1980 14:39-EST From: Mike McMahon To: MOON at MIT-AI cc: BUG-NWS at MIT-AI Moon@MIT-AI 04/16/80 04:41:51 In 27.6 on CADR-6, CC is completely broken. Keyboard input gets royally fucked over. Has CC ever worked in the NWS? I thought you were the only one who had claimed to have hacked it to try to work. I have not touched it at all, and so have no reason to believe it ever did.  Moon@MIT-AI 04/16/80 04:41:51 To: (BUG NWS) at MIT-AI In 27.6 on CADR-6, CC is completely broken. Keyboard input gets royally fucked over. Has CC ever worked in the NWS?  MMcM@MIT-AI 04/15/80 17:20:11 To: (BUG NWS) at MIT-AI The recent changes to the rubout handler's maintence of the cursor position cause very strange results when there are errors in read.  Date: 15 April 1980 10:49-EST From: Howard I. Cannon Subject: Defresource To: BUG-NWS at MIT-MC DEFRESOURCE now has syntax like: (DEFRESOURCE FOO ..) (DEFRESOURCE (FOO NIL) ...) (DEFRESOURCE (FOO T)...) The FOO and (FOO NIL) cases mean create a FOO if none exist at load time, and (FOO T) means don't bother. Also, I flushed all of the (GENSYM)'s from macros in NTVDEF... I probably broke something, so beware.  Date: 15 April 1980 10:05-EST From: Howard I. Cannon To: MOON at MIT-MC cc: BUG-NWS at MIT-MC There are keywords to explicitly control whether or not the initialization gets done the first time. It is trivial to add the keyword. In my opinion, it is not a bug in the initialization system...what is a bug is that it CANT listen to packages because "they are not in the cold load", which sucks. In any case, I'll add the appropriate keyword.  MOON@MIT-MC 04/15/80 04:43:35 To: (BUG NWS) at MIT-MC MMcM@MIT-AI 04/15/80 03:49:30 To: (BUG NWS) at MIT-AI How about making DEFRESOURCE cause one to be generated when the file is loaded, so you don't have to wait forever the first time? Good idea. There should be an option controlling it however, since some resources might be so rarely used and expensive that they would prefer not to have one pre-made.  MMcM@MIT-AI 04/15/80 03:49:30 To: (BUG NWS) at MIT-AI How about making DEFRESOURCE cause one to be generated when the file is loaded, so you don't have to wait forever the first time?  MMcM@MIT-AI 04/15/80 03:48:28 To: (BUG NWS) at MIT-AI In the version of NWS on system 27.4 nws, with microcode 618, on LISP Machine Six: All the old bugs should be fixed. This world seems to work alright, although it was built with spit and bailing wire because of bugs in the loading and ILLOP's in cold initializations. The pending incompatible changes should be made soon and another new world generated.  MOON@MIT-MC 04/15/80 03:19:12 To: (BUG NWS) at MIT-MC MMCM@MIT-AI 04/15/80 01:54:13 To: (BUG NWS) at MIT-AI the (WINDOW-INITIALIZE) that someone made go off the first time in WINTST doesn't work at that point in innumerable ways. Unless someone is volunteering to fix them, i put it back to only going off during booting. There was probably something wrong with the change, but I believe Hic and I made a change at that point that was motivated by the observation that it does not work to cold boot into the NWS if the machine has been powered off. The reason is that it references the TV memory before it has set up the sync program, and gets a nxm stop. There aren't enough old source versions online to figure out the details. In fact I can't figure out just what's going on now by looking at the code, I guess it depends on the order that initializations get on the system-initialization-list, which perhaps was getting screwed by the fact that there was already an initialization called WINDOW put on by the OWS? BTW, near the window add-initialization in WINTST there is a completely wrong comment. Something should be done about it. I don't delete it because maybe it means something (it's about initializing the keyboard). Is there also a misfeature in the initialization system that when you add an initialization, whether it gets done now depends on whether there was already an initialization with the same name (string-equal, regardless of packages), whether the code is the same or different? And there are two called "WINDOW"?  MMCM@MIT-AI 04/15/80 01:54:13 To: (BUG NWS) at MIT-AI the (WINDOW-INITIALIZE) that someone made go off the first time in WINTST doesn't work at that point in innumerable ways. Unless someone is volunteering to fix them, i put it back to only going off during booting.  MOON@MIT-AI 04/14/80 03:39:12 Re: Minor stylistic point To: (BUG NWS) at MIT-AI In macros that generate local variables, I think it would be better to use a name with hokey characters in it (e.g. dot) than to use gensym. The reason is that every expansion of this macro will use a different gensym, increasing the number of symbols around in the world. This is obviously not a major issue.  Date: 10 April 1980 19:42-EST From: Howard I. Cannon To: MMCM at MIT-AI cc: BUG-NWS at MIT-AI Why don't you just punt losenges in the cold load stream, or leave the stupid arrow font around (but perhaps rename it to loseng)... does it make all that much of a difference?  Date: 10 April 1980 19:28-EST From: Mike McMahon To: HIC at MIT-MC cc: BUG-NWS at MIT-AI Date: 10 April 1980 18:40-EST From: Howard I. Cannon Move the Losenge function if that's not too hard to do. I would have if it weren't. It knows too much about the sheet itself; there could be a similar function in COLD that did the things specific things that needs, or there it could be modularized differently.  HIC@MIT-AI 04/10/80 18:55:09 To: (BUG NWS) at MIT-AI While we are talking about incompatible changes to things like :VERIFY-NEW-EDGES, I think we should consider things like: A) There probably wants to be some sort of SHEET-FORCE-ACCESS wrapper around the :REFRESH message...I think almost everything that has a refresh after daemon does one by hand anyway. B) Looking at this margin refresh issue, which probably could be done better C) Also looking at set-edges in the same light (namely, some sort of wrapper to do the sheet-force-access that everyone probably does anyway --Howard  Date: 10 April 1980 18:40-EST From: Howard I. Cannon To: MMcM at MIT-AI cc: BUG-NWS at MIT-AI Move the Losenge function if that's not too hard to do.  MMcM@MIT-AI 04/10/80 17:40:12 To: (BUG NWS) at MIT-AI (COLD-LOAD-STREAM :TYO) appears to be the only thing that still uses FONTS:ARROW. Should the losenge function be moved or something else pulled?  Date: 10 April 1980 02:01-EST From: Howard I. Cannon To: BUG-NWS at MIT-MC Should we have something like KBD-TYI-HOOK that the user can bind, or set (or whatever) and that gets funcalled by the default io-buffer output function? DESTRY wanted something like this, and probably other people will too...  Moon@MIT-AI 04/09/80 01:21:03 Re: subtle bug (26.17) To: (BUG NWS) at MIT-AI I hit break out of the editor, called peek from the typeout window. After Q'ing out of peek, the typeout window has homed up and erased, because its bits weren't saved. I then hit c-Z and the editor didn't know that the whole display was clobbered, it only redisplayed the part previously covered by typeout.  Moon@MIT-AI 04/08/80 22:49:08 To: (BUG NWS) at MIT-AI There is a list of five pending incompatible changes on the front of the LMWIND;CHANGE MAIL listing.  Moon@MIT-AI 04/08/80 21:44:42 To: (BUG NWS) at MIT-AI It needs to be documented the convention that blinkers have their phase nil when the sheet is deexposed so that you can set their position, etc., without getting an output-hold.  Moon@MIT-AI 04/08/80 21:19:56 Re: Window EH To: (BUG NWS) at MIT-AI You can point to code in the stack, but clicking on it just flashes. It should grind it into the interaction window. I added c-m-W to the documentation. If you c-m-W from the typeout window of the editor, on return via Exit in the menu, it selects the editor instead of the typeout window, but doesn't redisplay the editor buffer until you hit a key. Presumably this is more problems with reselection.  HIC@MIT-AI 04/05/80 03:37:39 Re: Scrolling stuff To: (BUG NWS) at MIT-AI I hacked around with the scrolling stuff a bit, and I think it'll be better now about flushing the blinker if the text changes from under the mouse, and updating the scroll bar, and More Above and More Below, etc.. Anyway, if you notice any bugs (though it isn't installed), let me know (better yet, fix them!) --Howard