Date: 9 June 1981 00:55-EDT From: Mike McMahon To: BUG-NWS at MIT-AI In the version of nws in System 69.14, ZMail 27.13, microcode 757, on Lisp Machine Six: There is no easy way to reset a resource, i.e. cause a new one to be created when next needed. Also, killing a window-resource should disqualify it for resource allocation.  Date: 7 June 1981 04:00-EDT From: David A. Moon Subject: Infinite hair in choose-variable-values To: MMCM at MIT-AI cc: BUG-NWS at MIT-AI In the source files of LMWIN;CHOICE and ZMAIL;PROFIL are changes which make mouse documentation work right with the choose-variable-values, including for the :menu-alist type choices.  Date: 7 June 1981 00:29-EDT From: Howard I. Cannon Sender: PUCK at MIT-AI To: BUG-NWS at MIT-AI I just made a fair number of gratuitous changes to the window system initialization code designed to fix up the clearing of the screen lossage upon cold-booting (namely, it doesn't get cleared). Now, DISK-SAVE deexposes all the screens (don't ask me why I couldn't use the BEFORE-COLD initialization list, or I'll be forced to cry). The initial lisp listener is cleared explicitly. When the system comes up after a cold boot, all of the screens are exposed. This causes them to be refreshed correctly, and all the other right things to happen. The color screen conspires not to become exposed if there ain't no hardware there (it has done this forever anyway). Probably the next person who builds a system will discover all the new bugs. I tested it as best I could.  Date: 5 June 1981 21:35-EDT From: Howard I. Cannon To: rms at MIT-AI cc: BUG-NWS at MIT-AI Date: 5 June 1981 02:34-EDT From: Richard M. Stallman Sender: ___025 at MIT-AI To: BUG-NWS at MIT-AI I got an attempt to add NIL in something whose name contain the words "kludge", "more" and "lock" when a SUPDUP tried to complain that it wanted to type out while I was sitting in a **MORE** in my lisp listener. This error said it was using the cold load stream due to window system problems. It was after I C-Z'd it that the notification about the SUPDUP came out. I'm on the color machine on the 3rd floor. I fixed the probable cause of this bug. It looks like a fairly old bug, btw.  Date: 5 June 1981 02:34-EDT From: Richard M. Stallman Sender: ___025 at MIT-AI To: BUG-NWS at MIT-AI I got an attempt to add NIL in something whose name contain the words "kludge", "more" and "lock" when a SUPDUP tried to complain that it wanted to type out while I was sitting in a **MORE** in my lisp listener. This error said it was using the cold load stream due to window system problems. It was after I C-Z'd it that the notification about the SUPDUP came out. I'm on the color machine on the 3rd floor.  Date: 4 June 1981 22:04-EDT From: Mike McMahon To: BUG-NWS at MIT-AI BAK@MIT-AI 06/04/81 13:03:25 For all the various Profile options, how about including some documentation in the documentation line saying what one is when the mouse is over it. Currently it just says "Click left to change this value." Many of these lists are of the :MENU-ALIST type, which should somehow be able to get control of the who-line documentation to get the :DOCUMENTATION element out.  Date: 4 June 1981 15:22-EDT From: Howard I. Cannon To: BUG-NWS at MIT-MC Should SHEET-FORCE-ACCESS cause screen management of the window that access was forced on? This way, if a partially covered window is frobbed with, it will get updated. What are the speed penalties here?  Date: 3 June 1981 14:04-EDT From: James M. Turner Subject: (set-item-list) To: BUG-NWS at MIT-AI cc: JMTURN at MIT-AI In the version of NWS in System 69.4, ZMail 27.7, microcode 757, on Lisp Machine Eighteen: (set-item-list ITEMS), which is suppose to "Get or Set the list of items (choices). Setting the item-list recomputes the geometry and redisplays the menu", actually does not display the menu if it has not been exposed. It might be a good idea to stress that the window must have been exposed, or it will not be displayed [ref WP 208]. James Turner  Date: 3 June 1981 02:19-EDT From: David A. Moon Subject: Flashy scrolling misbehavior To: BUG-NWS at MIT-AI cc: JERRYB at MIT-AI Date: 1 June 1981 23:00-EDT From: Mike McMahon To: JERRYB at MIT-AI cc: BUG-NWS at MIT-AI JerryB@MIT-AI 06/01/81 10:50:32 Re: Lots of bugs In the version of ZMAIL in System 69.4, ZMail 27.4, microcode 757, on Lisp Machine Sixteen: In the profile, in the user options scroll window, the fat scroll arrow can appear but the items in the window are still sensitive to the mouse. Thus one can click the mouse with the intent of paging through the user items but end up unintentionally choosing an option. Flashy scrolling must have two ideas of the mouse region. Mouse clicks scrolling by a screenful are done by an entirely different mixin than the one that scrolls by a line when you push the fat arrow off the bottom. Thus it's likely that they would turn on at different times. Perhaps this should be changed, since they tend to be used together (that is, flashy scrolling is used without scroll regions, but not vice versa).  Date: 1 June 1981 23:00-EDT From: Mike McMahon To: JERRYB at MIT-AI cc: BUG-NWS at MIT-AI JerryB@MIT-AI 06/01/81 10:50:32 Re: Lots of bugs In the version of ZMAIL in System 69.4, ZMail 27.4, microcode 757, on Lisp Machine Sixteen: In the profile, in the user options scroll window, the fat scroll arrow can appear but the items in the window are still sensitive to the mouse. Thus one can click the mouse with the intent of paging through the user items but end up unintentionally choosing an option. Flashy scrolling must have two ideas of the mouse region. The list of options for the middle button of the map over command are too long, at least sort is not on this list and it should be. The user options window should be able to handle option lists without truncating them. The mouse documentation for the sort command doesn't say anything about what the middle button might do. This is fixed by the recent patches relevant to choose-variable-values.  Moon@MIT-MC 06/01/81 05:13:00 To: MMcM at MIT-AI CC: (BUG NWS) at MIT-AI Date: 28 May 1981 23:55-EDT From: Mike McMahon In the absence of horizontal scrolling, CHOOSE-VARIABLE-VALUES should not let things go off the right edge if possible. I guess this needs to be figured out before the window is exposed. I added total hair to choose-variable-values to do so. It seems to work. Will install as a path to system 29 so we can see if it has any lurking bugs.  HIC@MIT-MC 05/31/81 02:21:55 To: (BUG nws) at MIT-AI In System 69.2, ZMail 27.4, microcode 757, on Lisp Machine Six: Is there any reason that CHAR-ALUF and ERASE-ALUF aren't settable? I hope not, since I made them be.  Date: 28 May 1981 23:55-EDT From: Mike McMahon To: BUG-NWS at MIT-AI In the version of NWS in System 69.1, ZMail 27.2, microcode 757, on Lisp Machine Six: In the absence of horizontal scrolling, CHOOSE-VARIABLE-VALUES should not let things go off the right edge if possible. I guess this needs to be figured out before the window is exposed.  Date: 28 May 1981 15:31-EDT From: Gerald R. Barber Subject: Hardware/software TV speed confusion To: MOON at MIT-MC cc: DLW at MIT-AI, BUG-NWS at MIT-AI MOON@MIT-MC 05/23/81 15:26:28 Re: Hardware/software TV speed confusion To: dlw at MIT-AI CC: (BUG NWS) at MIT-AI, taft at MIT-AI Date: 23 May 1981 12:34-EDT From: Daniel L. Weinreb To: BUG-NWS at MIT-AI In the version of NWS in System 68.19, ZMail 26.8, microcode 752, on Lisp Machine Two: This bug report is only semi-substantiated. It appears that if you do (tv:set-tv-speed 67.) on a Lisp Machine (which people sometimes do in order to cut down on flicker), and then the machine is cold-booted, the hardware remains in 67. mode but the software assumes that it is in 60. mode. The symptom is that the wholine is not visible; it is being painted on bits that the physical TV is not actually displaying. Does cadr-2 have a prototype TV4B board, in which the prom sync program enable logic is totally screwed up? What is supposed to happen is that the software can read back whether the sync is coming from prom or not; on cold boot if it is coming from prom it leaves it alone. In the original print set for this board this logic is completely confused and doesn't work, and there seem to be some TV4B boards around containing various patches to this logic which make it behave in various different wrong ways. I fixed all the ones I found but maybe there is another in CADR-2. If this doesn't explain it, I am surprised. I don't know what kind of TV4B board cadr15 has but it does have the described ailment (in system 68.23). The wholine, mouse documentation line and run bars are not visible. Cold booting does not reset the world as it should.  Date: 24 May 1981 02:37-EDT From: David A. Moon Subject: Changing fonts of menus To: JERRYB at MIT-AI, BUG-NWS at MIT-AI In the next system there will be a :set-default-font message which menus will accept, which will change the font in which items that don't have a :font specifier are displayed. I fixed the bug that caused your doing this to tend to get out of bounds errors in %draw-rectangle; the :save-bits :delayed option was the culprit; it caused the window to get an illegal bit array. This is all a crock; if we ever make an incompatible change to the window system the locations-per-line instance variable should be flushed, and the microcode should compute this every time so that it will be right (it knows how to). Then the width of the bit array can be set to the correct width (rounded up to the next multiple of 32 bits) instead of the width of the screen.  Date: 24 May 1981 01:13-EDT From: Daniel L. Weinreb Subject: Changing sizes of SUPDUP windows. To: RWK at MIT-MC cc: BUG-NWS at MIT-AI I think the mouse documentation of Move Single is pretty clear. Calling it "Move Single Edge" would be wrong, since it moves either a single edge or a single corner. Yeah, I didn't LITERALLY mean "design feature"; we all know what the score is here.  Date: 23 May 1981 19:23-EDT From: Robert W. Kerns Subject: Changing sizes of SUPDUP windows. To: dlw at MIT-AI cc: BUG-NWS at MIT-AI Date: 23 May 1981 13:58-EDT From: Daniel L. Weinreb Subject: Changing sizes of SUPDUP windows. To: BUG-NWS at MIT-AI In the version of NWS in System 68.19, ZMail 26.8, microcode 752, on Lisp Machine Two: If you go into the screen editor and try to do a Move Single on a connected SUPDUP window, the screen editor bombs out to the EH in the cold-load stream. If you try to do Reshape, it is somewhat more elegant: it feeps. However, in both of these cases, it would be MUCH better to give the user an informative message, at least explaining that it is a design feature that you are not allowed to change the size of a connected SUPDUP window. Users tend to get confused when they get this feep, assuming they are giving the command incorrectly or something, and it's not surprising that they think this. I always thought that Move Single moved a single window. I see that I am wrong, but even the mouse documentation gives that impression. Nothing whatsoever indicates that it actually is a way to reshape a window. I think the name should be "Move Single Edge"; the brevity is spurious. And the mouse documentation should probably contain the word "reshape", as should Move Multiple Edges's documentation. However, I don't think you should claim that the inability to reshape a connected SUPDUP window is a design feature. Rather, it's constrained by the fact that the other end knows the size and there is no protocol for changing it. The "feature" was forced, not designed. If you claim it's a "design feature" somebody will certainly call it a "design misfeature". Perhaps "You can't change the size of a SUPDUP terminal or its window." is what you want the message to say.  Date: 23 May 1981 17:25-EDT From: Daniel L. Weinreb Subject: Hardware/software TV speed confusion To: MOON at MIT-MC cc: BUG-NWS at MIT-AI, TAFT at MIT-AI Well, the board says "TV #2" on it; I can't tell whether it is a "prototype TV4B board".  MOON@MIT-MC 05/23/81 15:26:28 Re: Hardware/software TV speed confusion To: dlw at MIT-AI CC: (BUG NWS) at MIT-AI, taft at MIT-AI Date: 23 May 1981 12:34-EDT From: Daniel L. Weinreb To: BUG-NWS at MIT-AI In the version of NWS in System 68.19, ZMail 26.8, microcode 752, on Lisp Machine Two: This bug report is only semi-substantiated. It appears that if you do (tv:set-tv-speed 67.) on a Lisp Machine (which people sometimes do in order to cut down on flicker), and then the machine is cold-booted, the hardware remains in 67. mode but the software assumes that it is in 60. mode. The symptom is that the wholine is not visible; it is being painted on bits that the physical TV is not actually displaying. Does cadr-2 have a prototype TV4B board, in which the prom sync program enable logic is totally screwed up? What is supposed to happen is that the software can read back whether the sync is coming from prom or not; on cold boot if it is coming from prom it leaves it alone. In the original print set for this board this logic is completely confused and doesn't work, and there seem to be some TV4B boards around containing various patches to this logic which make it behave in various different wrong ways. I fixed all the ones I found but maybe there is another in CADR-2. If this doesn't explain it, I am surprised.  Date: 23 May 1981 13:58-EDT From: Daniel L. Weinreb Subject: Changing sizes of SUPDUP windows. To: BUG-NWS at MIT-AI In the version of NWS in System 68.19, ZMail 26.8, microcode 752, on Lisp Machine Two: If you go into the screen editor and try to do a Move Single on a connected SUPDUP window, the screen editor bombs out to the EH in the cold-load stream. If you try to do Reshape, it is somewhat more elegant: it feeps. However, in both of these cases, it would be MUCH better to give the user an informative message, at least explaining that it is a design feature that you are not allowed to change the size of a connected SUPDUP window. Users tend to get confused when they get this feep, assuming they are giving the command incorrectly or something, and it's not surprising that they think this.  Date: 23 May 1981 12:34-EDT From: Daniel L. Weinreb To: BUG-NWS at MIT-AI In the version of NWS in System 68.19, ZMail 26.8, microcode 752, on Lisp Machine Two: This bug report is only semi-substantiated. It appears that if you do (tv:set-tv-speed 67.) on a Lisp Machine (which people sometimes do in order to cut down on flicker), and then the machine is cold-booted, the hardware remains in 67. mode but the software assumes that it is in 60. mode. The symptom is that the wholine is not visible; it is being painted on bits that the physical TV is not actually displaying.  Date: 18 May 1981 23:40-EDT From: Howard I. Cannon To: MOON at MIT-MC cc: BUG-NWS at MIT-MC I guess maybe the clobberage should be flushed, since it doesn't work. I'll look at it.  Moon@MIT-MC 05/18/81 19:59:02 To: HIC at MIT-MC CC: (BUG NWS) at MIT-MC HIC@MIT-MC 05/18/81 10:26:13 To: (BUG NWS) at MIT-MC I changed the source so that the who line is refreshed upon warm/cold boot. That means it now first gets clobbered by WINDOW-INTIALIZED then refreshed by this warm initialization. Is that the right thing?  Moon@MIT-MC 05/18/81 19:43:12 Re: Horrible problem that must be corrected immediately To: RWK at MIT-MC CC: (BUG NWS) at MIT-AI Date: 20 April 1981 20:08-EST From: Robert W. Kerns Subject: Horrible problem that must be corrected immediately To: BUG-LISPM at MIT-AI In System 67.4, ZMail 21.1, microcode 752, on Lisp Machine Sixteen: On cold boot, on the who line, just below the mouse documentation line, and above to the left of the "U" in "USER:", a small black turd appears, about 2 pixels high by maybe 10 wide. This offends my eyes and forces me immediately type TERMINAL-W to make it go away. It is fortunate that this works, or I would be forced to apply whiteout (turdout?) to my CRT. Fixed in the source. Someone spazzed and the various fields of the who-line were not contiguous. (I guess screen management on the who-line screen is suppressed somehow, or it would have been blanked out anyway.)  HIC@MIT-MC 05/18/81 10:26:13 To: (BUG NWS) at MIT-MC I changed the source so that the who line is refreshed upon warm/cold boot.  Date: 15 May 1981 15:12-EDT From: Gerald R. Barber Subject: Talk: A Graphics Editor for the Lisp Machine To: MMCM at MIT-AI cc: BUG-NWS at MIT-AI I agree, however I was only asked to put the word out when it was realized that it had not been announced on the system. I had nothing to do with the talk. There have been announcements posted in the elevator lobbies for several days.  Date: 15 May 1981 14:52-EDT From: Mike McMahon Subject: Talk: A Graphics Editor for the Lisp Machine To: JERRYB at MIT-AI cc: BUG-NWS at MIT-AI JERRYB@MIT-AI 05/15/81 13:38:31 Re: Talk: A Graphics Editor for the Lisp Machine Date: Fri. May 15, 1981 Time: 2:30 pm, refreshments at 2:15 pm It isn't very likely that you will get much attendance from the lisp machine window system maintainers by announcing a talk only 52 minutes in advance.  Date: 11 May 1981 17:48-EDT From: Mike McMahon To: DLW at MIT-AI cc: BUG-NWS at MIT-AI Date: 9 May 1981 00:57-EDT From: Daniel L. Weinreb In the version of ZMAIL in System 68.10, ZMail 26.4, microcode 752, on Lisp Machine Six: When I use Move To File/Find File, I can't read what the default file name is because the window is so narrow that it reaches the right end before it can print out an entire ITS pathname. Fixed in TV:SYSTEM-SET-EDGES, which somehow had the impression that deexposed temporary windows were special.  Date: 11 May 1981 14:57-EDT From: Mike McMahon To: BUG-NWS at MIT-AI Date: 10 May 1981 01:46-EDT From: Henry Lieberman TV:BORDERED-CONSTRAINT-FRAMES don't accept :SET-MOUSE-POSITION. As i recall, someone claimed something breaks when you add ESSENTIAL-MOUSE to frames. What is it?  Date: 9 May 1981 11:32-EDT From: Gerald R. Barber To: JMTURN at MIT-AI cc: BUG-NWS at MIT-AI Date: 9 May 1981 01:30-EDT From: James M. Turner In the version of NWS in System 68.9, ZMail 26.3, microcode 752, on Lisp Machine Eighteen: Actually, this bug occured on the color machine in 907. I was fooling around with the mouse on the color window, and managed to kill it off using the EDIT SCREEN menu selection. This left me with no way to move the mouse back to the main screen, or to create a new color window. It should be non-trivial to kill the uppermost color window. James Turner I have found that a useful [terminal] key is one that will cycle the mouse through the various screens that satisfy the SHEET-EXPOSED-P predicate. I put it on [terminal]-R for "Rotate mouse through exposed screens."  Date: 9 May 1981 01:30-EDT From: James M. Turner To: BUG-NWS at MIT-AI cc: JMTURN at MIT-AI In the version of NWS in System 68.9, ZMail 26.3, microcode 752, on Lisp Machine Eighteen: Actually, this bug occured on the color machine in 907. I was fooling around with the mouse on the color window, and managed to kill it off using the EDIT SCREEN menu selection. This left me with no way to move the mouse back to the main screen, or to create a new color window. It should be non-trivial to kill the uppermost color window. James Turner  Date: 7 May 1981 14:02-EDT From: Mike McMahon To: NIS at MIT-AI cc: BUG-NWS at MIT-AI Nis@MIT-AI 05/07/81 12:40:51 hi, in system 68.9 on cadr9 the choice window mechanism in the image window system doesnt work. things were working in system 67. mousing a variable and typing somthing in leaves nil there rather than the desired value. This was someone's careless use of CATCH-ERROR. I had fixed it when i rearranged that code. I made that part of my fixes a patch for 68.10 which should work.  Date: 4 May 1981 1113-EDT From: David L. Andre To: HIC at MIT-MC cc: BUG-NWS at MIT-AI, DLA at MIT-EECS In-Reply-To: Your message of 3-May-81 1712-EDT From: Howard I. Cannon To: DLA at MIT-AI What does "the wholine is changed" mean? I meant to say "the whostate is changed". I want to change the part which would be saying "RUN" to "CRUNCH" during the execution of a function... -------  Date: 3 May 1981 16:35-EDT From: Howard I. Cannon To: DLA at MIT-AI cc: BUG-NWS at MIT-AI Date: 3 May 1981 03:03-EDT From: David L. Andre To: BUG-NWS at MIT-AI In System 67.13, ZMail 21.2, microcode 752, on Lisp Machine Four: I would like to be able to do something like the following: (WHOSTATE-BIND "CRUNCH" (RUN-CRUNCHING-FUNCTION)) The properties of this WHOSTATE-BIND is that the wholine is changed to its first argument during the execution of RUN-CRUNCHING-FUNCTION. Does something like this exist? If not, it probably should. What does "the wholine is changed" mean?  Date: 3 May 1981 03:03-EDT From: David L. Andre To: BUG-NWS at MIT-AI In System 67.13, ZMail 21.2, microcode 752, on Lisp Machine Four: I would like to be able to do something like the following: (WHOSTATE-BIND "CRUNCH" (RUN-CRUNCHING-FUNCTION)) The properties of this WHOSTATE-BIND is that the wholine is changed to its first argument during the execution of RUN-CRUNCHING-FUNCTION. Does something like this exist? If not, it probably should.  HIC@MIT-MC (Sent by rwg@MIT-MC) 05/03/81 01:50:48 To: (BUG NWS) at MIT-MC I fixed a bug in the DELAYING-SCREEN-MANAGEMENT macro. It's not a serious one, but it might cause anamolous behavior from time to time (VERY rarely). The window system probably wants to be completly recompiled for the next load. It is compatible, however, so this is not absolutly necessary.  MOON@MIT-MC 05/02/81 16:54:10 Re: separate-program version of INSPECT function To: HIC at MIT-MC CC: CWH at MIT-MC, RWK at MIT-MC, DLW at MIT-AI, (BUG NWS) at MIT-AI When the program system exists hopefully there will be a general run-program name &rest arguments function.  Date: 2 May 1981 00:53-EDT From: Howard I. Cannon To: DLW at MIT-AI cc: CWH at MIT-MC, RWK at MIT-MC, BUG-NWS at MIT-AI Date: 1 May 1981 13:45-EDT From: Daniel L. Weinreb To: RWK cc: BUG-NWS at MIT-AI, CWH I agree about the System-I version of the INSPECT function. How about calling it INSPECTOR? That sounds absurdly confusing, but I agree in principal. I'll think.  Date: 2 May 1981 00:33-EDT From: Carl W. Hoffman To: BUG-NWS at MIT-AI In the version of NWS in System 67.13, ZMail 21.2, microcode 752, on Lisp Machine Fifteen: Could you add an option to the System key for creating an editing lisp listener?  rwg@MIT-MC 05/01/81 23:46:57 To: (BUG nws) at MIT-AI In System 66.19, ZMail 20.5, microcode 751, on Lisp Machine One: Mouse documentation for left scrollbar of ZWEI says L:Bottom line to blinker. Should say L:Mouse line to top. (Inverse of R:)  Date: 1 May 1981 13:45-EDT From: Daniel L. Weinreb To: RWK at MIT-MC cc: BUG-NWS at MIT-AI, CWH at MIT-MC I agree about the System-I version of the INSPECT function. How about calling it INSPECTOR?  Date: 1 May 1981 09:49-EDT From: Gerald R. Barber To: MMCM at MIT-AI, RWK at MIT-MC cc: BUG-NWS at MIT-AI, CWH at MIT-MC Date: 1 May 1981 02:29-EDT From: Robert W. Kerns To: MMCM at MIT-AI cc: CWH at MIT-MC, BUG-NWS at MIT-AI Date: 30 April 1981 03:00-EDT From: Mike McMahon To: CWH at MIT-MC cc: BUG-NWS at MIT-AI Date: 30 April 1981 02:23-EST From: Carl W. Hoffman I would prefer the INSPECT function to be more similar to System-I, i.e. run in its own process, rather than the process it is typed in, and to use the same set of windows that System-I uses. That would make it impossible to do inspect for value, something that Howard and i at least do all the time. I would like the functionality of having a separate process. I am willing to use a different name. I'm even willing to write it myself, but I think this should be made a part of the system. I don't know what a good alternate name would be. I would also like having the option of a inspector in its own process: something that would send an object to the inspector that system-i would get and then select it.  Date: 1 May 1981 0053-EDT From: Mike McMahon Reply-to: MMCM@MIT-AI To: bug-nws at MIT-AI The way keywords for the variable types for choose-variable-values are defined is pretty unsatisfactory. It should be driven off a plist or at least defined via a macro so that other programs can add new ones. -------  Date: 1 May 1981 02:29-EDT From: Robert W. Kerns To: MMCM at MIT-AI cc: CWH at MIT-MC, BUG-NWS at MIT-AI Date: 30 April 1981 03:00-EDT From: Mike McMahon To: CWH at MIT-MC cc: BUG-NWS at MIT-AI Date: 30 April 1981 02:23-EST From: Carl W. Hoffman I would prefer the INSPECT function to be more similar to System-I, i.e. run in its own process, rather than the process it is typed in, and to use the same set of windows that System-I uses. That would make it impossible to do inspect for value, something that Howard and i at least do all the time. I would like the functionality of having a separate process. I am willing to use a different name. I'm even willing to write it myself, but I think this should be made a part of the system. I don't know what a good alternate name would be.  Date: 30 April 1981 11:01-EDT From: Gerald R. Barber Subject: Changing fonts in menus. To: BUG-NWS at MIT-AI In the version of NWS in System 67.13, ZMail 21.2, microcode 752, on Lisp Machine Fifteen: I am trying to change the font for some existing menus. The reasonable thing to do would seem to be to send a ':set-font-map message to the menu. But this doesn't work because the right things aren't notified that the font has changed and sending ':set-current-font doesn't help. An explicit ':set-geometry with no args works in some cases but in some cases it gets a "%draw-rectangle attempted to erase past edge of screen". This only happens in some cases and doesn't seem to depend on where the menu was last used. I had problems especially with the menu in the tv:auxiliary-menu resource. There should be an easier way to do something this simple.  Date: 30 April 1981 03:00-EDT From: Mike McMahon To: CWH at MIT-MC cc: BUG-NWS at MIT-AI Date: 30 April 1981 02:23-EST From: Carl W. Hoffman I would prefer the INSPECT function to be more similar to System-I, i.e. run in its own process, rather than the process it is typed in, and to use the same set of windows that System-I uses. That would make it impossible to do inspect for value, something that Howard and i at least do all the time.  Date: 30 April 1981 02:23-EST From: Carl W. Hoffman To: BUG-NWS at MIT-AI In the version of NWS in System 67.13, ZMail 21.2, microcode 752, on Lisp Machine Fifteen: I would prefer the INSPECT function to be more similar to System-I, i.e. run in its own process, rather than the process it is typed in, and to use the same set of windows that System-I uses.  Date: 29 April 1981 11:13-EDT From: Daniel L. Weinreb To: BUG-NWS at MIT-AI, CWH at MIT-MC Date: 28 April 1981 19:09-EST From: Carl W. Hoffman Typing Network L in a supdup window which is disconnected causes an error. Fixed in the source, not patched.  Date: 28 April 1981 19:09-EST From: Carl W. Hoffman To: BUG-NWS at MIT-AI In the version of NWS in System 67.13, ZMail 21.2, microcode 752, on Lisp Machine Fifteen: Typing Network L in a supdup window which is disconnected causes an error.  Date: 24 April 1981 20:43-EST From: Mike McMahon To: DLW at MIT-AI cc: BUG-NWS at MIT-AI Date: 24 April 1981 16:24-EST From: Daniel L. Weinreb What is the point of the MAX of 26. in TV:SHEET-NEW-FONTS-MAP? If it is supposed to assure that there are at least 26. elements in the font map, then someone ought to check the array that the user might equally well have passed in. If not, what is it for? Do we want to document that there is a guaranteed minimum size for font maps? It is for the editor, which calls fonts A through Z. It never passes in its own array.  Date: 24 April 1981 16:24-EST From: Daniel L. Weinreb To: BUG-NWS at MIT-AI In the version of NWS in System 67.11, ZMail 21.2, microcode 752, on Lisp Machine Nine: What is the point of the MAX of 26. in TV:SHEET-NEW-FONTS-MAP? If it is supposed to assure that there are at least 26. elements in the font map, then someone ought to check the array that the user might equally well have passed in. If not, what is it for? Do we want to document that there is a guaranteed minimum size for font maps?  Date: 23 April 1981 14:17-EST From: Daniel L. Weinreb Subject: Color fonts To: BUG-NWS at MIT-AI The function color:make-color-font, in LMWIN; COLOR >, which creates a color version of a black-and-white font, seems to just copy a pointer from the b&w font's char-width table and left-kern table into the new font. Thus the two fonts share these tables. If you then go and edit one of the fonts, then the other one will get clobbered, which doesn't seem like the defined behavior. Should these arrays be copied? Also, by the way, the color font's char-exist-table is not set up at all.  Date: 21 April 1981 04:46-EST From: Brad E. Pines To: BUG-NWS at MIT-AI When using the message :draw-cubic-spline I kept getting the same error when running. The error was that my first argument to *DIF,NIL was of the wrong type the function expected a number. This error kept repeating no matter what I used for the inputs to :draw-cubic-spline. Am I doing something wrong or is this a bug? I couldn't even find the function *DIF in the error handler but I am a little inexperienced in using the error handler.  Moon@MIT-MC 04/21/81 04:10:49 To: (BUG nws) at MIT-AI In the version of nws in System 67.9, ZMail 21.1, microcode 752, on Lisp Machine Six: If you edit TV:SPLIT-SCREEN-ITEM-LIST to be bigger (e.g. stick more blank lines in the menu), re-evaluate it, then go Split Screen, it gets an attempt to draw off bottom of window error, erasing the margins, inside of :CHANGE-OF-SIZE-OR-MARGINS inside of :SET-INSIDE-SIZE. This is quite reproducible. I was not able to find any reason for this. Setting %CURRENT-SHEET to NIL at the appropriate place does not make it go away. This needs to be looked at more carefully.  Date: 20 April 1981 20:08-EST From: Mike McMahon To: RMS at MIT-AI cc: BUG-NWS at MIT-AI RMS@MIT-AI 04/19/81 20:15:31 2) I terminated a reply and then typed M. ZMAIL changed the window configuration back to the normaly one and then changed it again to that for M. Since these changes are so slow, they should certainly not happen if there is type ahead. The editor should remember which windows are supposed to be exposed and expose them if it is time to display. Configuration switching uses the frame configuration switching mechanism, which provides no such memory.  Date: 19 April 1981 21:21-EST From: Daniel L. Weinreb To: MOON at MIT-AI cc: BUG-NWS at MIT-AI Date: 18 April 1981 03:23-EST From: David A. Moon I removed some brain-damage from HACKS:WITH-REAL-TIME that caused it never to restore the sequence-break mode when you exited the hack. The entire hacks package should be recompiled some time. Argh. Well, (SI:SB-ON) is really not a good way to say "I'd like to read the state of the SB setting without affecting it." Defining things this way to save a random function is tantamount to storing constants in the right halves of POPJs.  Date: 19 April 1981 20:46-EST From: Daniel L. Weinreb To: BUG-NWS at MIT-AI In the version of NWS in System 67.5, ZMail 21.1, microcode 752, on Lisp Machine Seven: If you click "Select File" in Zmail, and get the submenu, and position the mouse over "Find File", then the box drawn around the words "Find File" is not positioned exactly right; the "e" at the end extends past the box.  Date: 18 April 1981 03:23-EST From: David A. Moon To: DLW at MIT-AI cc: BUG-NWS at MIT-AI I removed some brain-damage from HACKS:WITH-REAL-TIME that caused it never to restore the sequence-break mode when you exited the hack. The entire hacks package should be recompiled some time.  Date: 18 April 1981 02:31-EST From: David A. Moon Subject: Complaints about Split Screen To: RMS at MIT-AI cc: WALKER at MIT-AI, BUG-NWS at MIT-AI I fixed them all in the source.  Date: 18 April 1981 01:50-EST From: David A. Moon Subject: Lossage typing comma at trace window To: BUG-NWS at MIT-AI cc: ZVONA at MIT-AI Two bugs here: one is the trace window wasn't setting up its streams correctly, which I fixed in the source. The other is that (:METHOD SELECT-MIXIN :MOUSE-SELECT) imagines it frees temporary locks but doesn't actually do so, which is why terminal-0-s hangs and so forth. It has to free temporary locks on all windows it would need to deexpose in order to select this one, not just on the one being selected. All over the system it assumes that the :MOUSE-SELECT message is the way you select something without having to worry about temporary locks. I think we have discussed this before.  Date: 15 April 1981 22:57-EST From: Jan Walker To: BUG-NWS at MIT-AI In the version of NWS in System 66.15, ZMail 20.3, LM-File-System 1.0, microcode 747, on Lisp Machine Three: Inside option ANY of Split Screen in the system menu, it pops up a window to ask for the type of window to include. Typing Abort at this time aborts the entire Split Screen operation. That should take a M-Abort, and Abort should just abort the ANY operation. ANY should probably be renamed to "You specify type" or "user-specified type" or "any other type". Undo should be "Undo Last" or "Undo Last Selection". Although selecting Frame and specifying "No" is probably a no-op, I don't feel confident of that. There ought to be a way of changing your mind about using a frame that makes the frame window go away entirely. Perhaps, if the mouse moves out of the Frame options window while the answer to the question is "no" then the frame options window should go away. Also, it's a little unclear that the first question means "should I really do this at all". The natural expectation is that it is some sub-option -- what to do with the frame -- since by selecting Frame one has presumably already answered in the affirmative about wanting one. It would be better to have an Abort option in the frame options window.  Date: 15 April 1981 21:22-EST From: David A. Moon Subject: :draw-wide-curve To: BUG-NWS at MIT-AI cc: PINES at MIT-AI Date: 15 April 1981 04:13-EST From: Brad E. Pines To: BUG-NWS at MIT-AI To: bug-nws@mit-aiwhen using the function :draw-wide-curve the line are not completely fill in from one point to another. This is difficult. The immediate cause of your problems is that the method does not always draw rectangles, instead it draws quadrilaterals which each share one edge. Thus if your curve has a sharp bend in it the quadrilateral after the bend degenerates into a triangle. I fixed that but then it introduced the problem of getting gaps at sharp bends because the edges don't match up. The code in AI:MOON;WIDE CURVE is the result of my attempts, but I don't want to install it because it doesn't work in XOR mode, I'm not sure it works in all cases in IOR mode, and clearly a cleverer technique is called for.  Date: 15 April 1981 21:17-EST From: Mike McMahon Subject: inspector bug To: CARLF at MIT-AI, JERRYB at MIT-AI, CWH at MIT-MC cc: BUG-NWS at MIT-AI Date: 26 MAR 1981 2019-EST From: CARLF at MIT-AI (Carl Richard Feynman) When I put the PKG-REFNAME-ALIST of the GLOBAL package in the bottom window of the inspector, and ... Date: 27 MAR 1981 1126-EST From: JerryB at MIT-AI (Gerald R. Barber) Date: 26 MAR 1981 2019-EST From: CARLF at MIT-AI (Carl Richard Feynman) I have had this problem several times also. The specific problem was that one of the arguments to %DRAW-LINE was NIL. This happened when it was trying to draw the bottom line of a list. The local variable LAST-RIGHT-X was NIL in the last call to %DRAW-LINE in the method (FOLLOW-LIST-STRUCTURE-BLINKER :BLINK). Why this happened I don't know. It is not very reproducible but happens "often" under the circumstances that CARLF describes. Date: 1 APR 1981 1032-EST From: JerryB at MIT-AI (Gerald R. Barber) Try looking at tv:system-windows with the inspector. ... Date: 15 April 1981 11:17-EST From: Carl W. Hoffman I was inside the inspector looking at a large piece of list structure in the bottom window. ... Fixed and patched for system 67.  Date: 15 April 1981 13:32-EST From: Mike McMahon To: KENT at MIT-AI cc: BUG-NWS at MIT-AI Date: 15 April 1981 09:41-EST From: Kent A. Stevens The window-creation option: :blinker-p nil does not seem to exist yet. This option has always existed so far as i know. What exactly are you doing that leads you believe it does not?  Date: 15 April 1981 11:17-EST From: Carl W. Hoffman To: BUG-NWS at MIT-AI In the version of NWS in System 66.17, ZMail 20.3, microcode 747, on Lisp Machine Six: I was inside the inspector looking at a large piece of list structure in the bottom window. The list structure was really a dtp-select-method which I had done (%make-pointer dtp-list ...) of. I had the mouse at the bottom of the window and was clicking it to page forward by screenfuls. On the second screenful, I was switched to the cold load stream with the error Third argument to SYS:%DRAW-LINE was NIL. Inside (METHOD TV:FOLLOW-LIST-STRUCTURE-BLINKER BLINK) I typed Z at that point, and got Restarting the scheduler. Blasting # so this won't happen again. Then the machine hung. Warm booting wouldn't work. Aside: I would appreciate an option in the inspector to allow select-methods to be viewed either in alphabetical order or the order in which they methods appear. The latter is useful when using the :SELECT-METHOD-ORDER option.  Date: 15 April 1981 11:04-EST From: Carl W. Hoffman To: BUG-NWS at MIT-AI In the version of NWS in System 66.17, ZMail 20.3, microcode 747, on Lisp Machine Six: When creating a window, how about filtering TV:NAME through something similar to ZWEI:MAKE-COMMAND-NAME? "Lisp Listener 3" is a little more pleasant than "LISP-LISTENER-3". Maybe a mixin?  Date: 15 April 1981 06:55-EST From: Brad E. Pines To: BUG-NWS at MIT-AI This is a note to my previous message about the faulty :draw-wide-curve message. I forgot to state that the bug shows up after the first line segment is drawn. The first line segment is drawn correctly but all others have the bug.  Date: 15 April 1981 04:13-EST From: Brad E. Pines To: BUG-NWS at MIT-AI To: bug-nws@mit-aiwhen using the function :draw-wide-curve the line are not completely fill in from one point to another. If you atempt to use a wide line the line starts out blank at the starting endpoint of a segmemt and get increasingly wider as you near the other endpoint of the segment. The line assumes the correct width about halfway between the endpoints. This process starts all over with the next segment to be drawn. The function :draw-curve works correctly.  MOON@MIT-MC 04/13/81 12:18:31 To: CWH at MIT-MC CC: (BUG NWS) at MIT-AI Date: 13 April 1981 05:36-EST From: Carl W. Hoffman To: BUG-NWS at MIT-AI In the version of NWS in System 66.18, ZMail 20.4, microcode 747, on Lisp Machine Fifteen: Inside the method (SELECT-MIXIN :NAME-FOR-SELECTION), the form (STRING-SEARCH-NOT-CHAR #\SP LABEL) appears. Isn't this just the same as (NOT (EQUAL LABEL "")) ? You have Lisp confused with PL/I. Spaces in strings are significant in Lisp. I think what you wanted was (NOT (STRING-SEARCH-CHAR #\SP LABEL)). That would mean "there are no spaces in the label". The code as written means "there are any non-blank characters in the label".  Date: 13 April 1981 06:58-EST From: Carl W. Hoffman To: BUG-NWS at MIT-AI In the version of NWS in System 66.18, ZMail 20.4, microcode 747, on Lisp Machine Fifteen: Page 48 of DLW;WINDOC 97 claims that the specification given to the :set-label method can be anything accepted by the :label init option. Passing just a font sets both the string and the font slots of the label to the font. Passing (:string "George" :font fonts:hl10b) works, but passing just (:font fonts:hl10b) errs out. There seem to be lots of other bugs in this code. I'll send more if you want. They're pretty easy to find by just playing around and trying different things.  Date: 13 April 1981 05:36-EST From: Carl W. Hoffman To: BUG-NWS at MIT-AI In the version of NWS in System 66.18, ZMail 20.4, microcode 747, on Lisp Machine Fifteen: Inside the method (SELECT-MIXIN :NAME-FOR-SELECTION), the form (STRING-SEARCH-NOT-CHAR #\SP LABEL) appears. Isn't this just the same as (NOT (EQUAL LABEL "")) ? I think what you wanted was (NOT (STRING-SEARCH-CHAR #\SP LABEL)).  Date: 10 April 1981 03:40-EST From: Carl W. Hoffman To: BUG-NWS at MIT-AI In the version of NWS in System 66.15, ZMail 20.2, Macsyma 15.0, microcode 747, on Lisp Machine Sixteen: Could someone please replace the third instance of the wired in constant 26 in TV:SHEET-NEW-FONT-MAP with (ARRAY-DIMENSION-N 1 NEW-MAP) as is done with TV:SHEET-DEDUCE-VSP. This would allow users to create their own font maps which don't happen to have 26 elements.  Date: 7 April 1981 22:42-EST From: Carl W. Hoffman To: BUG-NWS at MIT-AI In the version of NWS in System 66.15, ZMail 20.3, microcode 747, on Lisp Machine Sixteen: I would sure appreciate it if Terminal-ClearScreen would home the cursor when typed in a Telnet window.  Date: 5 April 1981 19:23-EST From: Carl W. Hoffman To: BUG-NWS at MIT-AI In the version of NWS in System 66.15, ZMail 20.2, microcode 747, on Lisp Machine Fifteen: In the Inspector, when the mouse is in the history window, the documentation window should show the meaning of the mouse buttons.  Date: 2 April 1981 16:22-EST From: Mike McMahon To: BUG-NWS at MIT-AI Something should manage to keep more than one process from being able to use the pop-up finger window.  Date: 1 April 1981 20:31-EST From: Robert W. Kerns Subject: SUPDUP/ZMAIL interaction, with new embellishments To: BUG-NWS at MIT-AI In the version of NWS in System 66.12, ZMail 20.0, microcode 747, on Lisp Machine Fifteen: While in one-window'd REPLY mode of ZMAIL, I did mouse-right (with the mouse over the message window). At that very instant, my SUPDUP typeout process wanted to type out. My mode line then said "Temp Lock", so I did TERMAINAL-CALL, and (DESCRIBE TV:SELECTED-WINDOW) showed it to be locked by the SUPDUP typeout process, as I expected from experience. (No notification was printed, as per usual with ZMAIL Reply). I did [RESUME], TERMINAL-CONTROl-CLEAR-INPUT, and the system and ZMAIL-REPLY menus both popped up, one on top of the other (I probably did mouse-right or mouse-right-twice before I realized what happened). Moving the mouse off of them, they popped down, and then the ZMAIL frame did too, brining up the SUPDUP frame (!), which of course had it's typeout process wedged waiting on the usual never-exposed ZMAIL window. I incanted my usual FIX-SUPDUP function. I wouldn't report this again except for the additional (amusing) embellishments it had to offer today. I'd never have expected it to de-expose my ZMAIL frame automagically! And the interaction with the menu may be significant. How about putting a function on the STATUS key to say "Your SUPDUP is wedged" or "Your SUPDUP is not wedged"? (Or maybe just "You are wedged"?)  Date: 1 April 1981 14:43-EST From: Daniel L. Weinreb Subject: Create (Expand) in the screen editor. To: ALAN at MIT-MC cc: BUG-NWS at MIT-AI Having received no comments from anyone, I have changed the "Create (expand)" command in the screen editor so that if you select a point on top of an exposed window, it doesn't worry about overlapping the window that you are on top of, and expands so that it doesn't overlap any of the other exposed windows. This is in a patch (66.12, I think) so you can try it out.  Date: 24 MAR 1981 0423-EST From: DLA at MIT-AI (David L. Andre) To: (BUG NWS) at MIT-AI In the version of NWS in System 65.30, ZMail 19.4, microcode 739, on Lisp Machine Six: Is :MOUSE-SELECT going to be changed to a noop by DONT-SELECT-WITH-MOUSE-MIXIN? This was discussed before, I think... -- Dave  Date: 22 March 1981 03:00-EST From: Alan Bawden Subject: Create (Expand) in the screen editor. To: dlw at MIT-AI cc: BUG-NWS at MIT-AI Date: 22 March 1981 01:31-EST From: Daniel L. Weinreb The "Create (Expand)" command works fine for me. Perhaps you are trying to use it and selecting an area on top of an exposed window. It doesn't know what to do in this case, since "Expand" means that it should only use surrounding area belonging to no exposed window, and there isn't any such area. Right now it reacts by doing nothing. We could change it to feep or change it to not include that window as one of the expanded windows when it looks for space. Which of these is better? Well, it is clear what you want in the case that you click over an exposed window (you clearly aren't thinking of it as exposed, otherwise you wouldn't have pointed there). It would have never occured to me that that was the reason that it "didn't work". It is usually unnecessary for the user to understand what "Exposed" means anyway (it's a fairly natural concept usually) so expanding "Create (Expand)"'s behavior in this way doesn't violate anthing real.  Date: 22 March 1981 01:31-EST From: Daniel L. Weinreb Subject: Create (Expand) in the screen editor. To: ALAN at MIT-AI, BUG-NWS at MIT-AI The "Create (Expand)" command works fine for me. Perhaps you are trying to use it and selecting an area on top of an exposed window. It doesn't know what to do in this case, since "Expand" means that it should only use surrounding area belonging to no exposed window, and there isn't any such area. Right now it reacts by doing nothing. We could change it to feep or change it to not include that window as one of the expanded windows when it looks for space. Which of these is better?  Date: 21 March 1981 07:42-EST From: Robert W. Kerns Subject: Scroll Bar Mouse Documentation To: BUG-NWS at MIT-AI In the version of NWS in System 65.29, ZMail 19.4, microcode 739, on Lisp Machine Sixteen: The documentation for the normal scroll bar (like in ZWEI and the ZMAIL summary window) says "Left: bottom line to blinker;", when in fact, it does no such thing. It moves the line the blinker is on to the top of the window. While this moves the bottom line up, which is toward the blinker, the amount moved INCREASES as the blinker is moved toward the bottom of the window, while the documentation would imply this DECREASES. The middle and right documentation is correct.  RWK@MIT-MC 03/20/81 23:02:30 Re: Notifications To: (BUG NWS) at MIT-MC I'm pretty sure I've seen this when I was simply editing a reply, with no window system hackery going on at all. When it happens to me, I don't even see any notification window, and when a notification window does pop up, I have had problems with all of a sudden getting 10e6 notifications with the **MORE** processing not helping for some reason (the **MORE** appears, but it doesn't pause). One circumstance this last happened with, sadly, was with space-low warnings. I don't think I've ever seen a notification while I was in ZMAIL Reply mode. But only SUPDUP gets wedged by this. I suspect ZMAIL Reply is the culprit here.  Date: 20 MAR 1981 2239-EST From: Moon at MIT-AI (David A. Moon) Subject: RWK's notification problem To: (BUG NWS) at MIT-AI, RWK at MIT-MC Son of a gun! After trying and failing to reproduce it, it happened to me while I was just reading my mail. I had typed ahead R, the reply, and END. The reply window popped up but didn't redisplay, then I got a supdup notification and the zmail went into lock. The zmail-window was locked by the supdup process, which was trying to print a notification not on the proper echo-area that goes with that window's mode-line-pane, but rather on a deexposed echo-area that belonged to zmacs-mode-line-window-1 which was deactivated and had a superior of the main screen!!! I don't know where supdup dug up this window from (other than that it obviously came from a :print-notification message to the selected window). An additional probably unrelated problem I happened to notice is that tv:careful-notify can hang even when careful-p is t, trying to :activate a typeout-window, because tv:sheet-can-activate-inferior doesn't like it. I would be the first to admit that careful-notify is a kludge.  Date: 19 March 1981 21:41-EST From: Robert W. Kerns Subject: SUPDUP hangage, and such To: BUG-NWS at MIT-AI cc: BUG-ZMAIL at MIT-MC In the version of NWS in System 65.26, ZMail 19.3, microcode 739, on Lisp Machine Sixteen: I have several times observed that while in reply mode in ZMAIL, (with the reply window taking up the entire screen) that I will get a notification, it will beep, and the wholine state goes to Lock. I haven't tried to find who locked who yet, but will next time it's convenient if this isn't enough info. When the notification is from SUPDUP, the SUPDUP:TYPEOUT-PROCESS goes into Output-hold until I incant run my FIX-SUPDUP program to reset it. I have not seen this problem anywhere else since Moon's fix to the notification stuff.  Date: 19 Mar 1981 1234-EST From: David L. Andre To: DLW at MIT-AI cc: JERRYB at MIT-AI, BUG-NWS at MIT-AI, DLA at MIT-EECS In-Reply-To: Your message of 18-Mar-81 1455-EST I aggree with JerryB, :SETTABLE-INSTANCE-VARIABLES should not be automatically gettable. That's counterintuitive and unnecessary, and the feature shouldn't be used in "readable" code anyway. -------  RWK@MIT-MC 03/19/81 09:42:28 Re: Mouse documentation To: DLW at MIT-MC CC: (BUG NWS) at MIT-MC Well, how about the best of both worlds? A process that updates it in the background (every 1/4 second would be better, I think) for the higher overhead situations, and immediate update for the more usual situation, like menus?  Date: 19 March 1981 03:21-EST From: Daniel L. Weinreb Subject: Experimental results To: RWK at MIT-MC cc: BUG-NWS at MIT-AI Well, as we improve the mouse documentatin to be not just fixed strings but computed quantities (it has been suggesed that Zmail should show, in the documentatin line, the default values that the left button will get you; whether this particular thing gets done or not, other things of this sort WILL get done), then the efficiency might really be degraded.  Date: 18 MAR 1981 2133-EST From: RMS at MIT-AI (Richard M. Stallman) To: (BUG NWS) at MIT-AI I agree that the window that a background process error is handled in should never be considered by System L. Those windows should be thought of as background error windows, not as Lisp windows.  Date: 18 March 1981 19:15-EST From: Robert W. Kerns Subject: Experimental results To: DLW at MIT-AI cc: BUG-NWS at MIT-AI Hang on. RWK, Moon is right that in general the updating of the mouse prompt line should only be one once per second the way it is now. Otherwise, most uses of the mouse would really be slowed down, and for most uses of the mouse speed is quite important whereas being able to look at the documentation line within a split-second is not so important (after all, it takes some time to read the line). [--DLW] Well, the worst case I can think of is moving the mouse from the message window of ZMAIL to the survey window, through the menu window. This would pop down the ZMACS info, pop up 3 menu items, pop down the last one, and pop up the summary line documentation. Somewhat worse cases would be generated by moving through even larger menus. But this doesn't seem all that bad. A few days ago HIC suggested I try it out and see how it looks. I have modified my environment to do (FUNCALL TV:WHO-LINE-DOCUMENTATION-WINDOW ':UPDATE) at all the apropriate points (TV:MOUSE-DEFAULT-HANDLER (at the beginning and where it enters and exit scroll bar) and (:METHOD TV:BASIC-MENU :MOUSE-MOVES)) and I have no reason to complain about mouse slowness. I can't tell the difference, except the documentation line is a lot more responsive. One hidden advantage that I didn't expect, is that it calls attention to where there is differing documentation, pointing out interesting places to mousing. It also wins moving horizontally accross the menu. But assume that my experiment is lacking somehow, and the cost is too high. We can still achieve exactly the same number of documentation-line changes as are performed currently. By the simple expedient of not performing updates if the speed is above a certain threshold, the mouse process can even optimize out the ones that would be shown for too short a time to be read, without sacraficing responsiveness. However, in the case of the control-meta bit prompting used in Daedalus and Muzacs and such, it IS important to update it immediately, since you interact with that prompt at very high speed, and especially since you often cycle through the combinations of control-meta bits looking for a command. [-- DLW] I interact with menu prompts at high speed, sometimes looking through several items looking for a command, or just perusing what's available in a new mode. While it is true that it takes some time to read the line, it takes a lot less time than the current 1/2 second average delay to point to a menu item and look down at the black bar (easily found due to convenient inverse video) to START reading. In fact, I'll bet much of the time I could glance down AND read it in that time, for simple prompts. The response to :who-line-mouse-documentation ought to work as Moon says, so that the right documentation will come up if you happen to move the mouse into that area, but also there should be something that simply watches the control-meta bits and calls the function that updates the mouse documentation line whenever they change (and it thinks that the user is using a program that uses mouse-clicks with control-meta bits to mean something). This seems simplest and most robust. [-- DLW] Great! Something we all agree on.  Date: 18 March 1981 15:02-EST From: Daniel L. Weinreb Subject: Mouse documentation and bucky-mouse To: RWK at MIT-MC cc: BUG-NWS at MIT-AI In fact, this brings to mind another gripe I have about mouse handling, namely that it doesn't see mouse-clicks when it's running.... The reason for this is that the seeing of mouse-clicks is done by the mouse process. If some other process hogs the machine, the mouse-process doesn't get run often enough to see the buttons moving. (I'm not saying this is a win or anything, I'm just answering your question about why it is the way it is right now.) Presumably the right way to do things is considerably simpler than what was in your message; the :WHO-LINE-MOUSE-DOCUMENTATION method should do a TV:KEY-STATE and decide which string to return... [-- Moon] I don't see this as being simpler, or even all that different. SOMEBODY has to notice that the keystate has changed, and a hell of a lot faster than the wholine notices it now! [-- RWK] Hang on. RWK, Moon is right that in general the updating of the mouse prompt line should only be one once per second the way it is now. Otherwise, most uses of the mouse would really be slowed down, and for most uses of the mouse speed is quite important whereas being able to look at the documentation line within a split-second is not so important (after all, it takes some time to read the line). However, in the case of the control-meta bit prompting used in Daedalus and Muzacs and such, it IS important to update it immediately, since you interact with that prompt at very high speed, and especially since you often cycle through the combinations of control-meta bits looking for a command. The response to :who-line-mouse-documentation ought to work as Moon says, so that the right documentation will come up if you happen to move the mouse into that area, but also there should be something that simply watches the control-meta bits and calls the function that updates the mouse documentation line whenever they change (and it thinks that the user is using a program that uses mouse-clicks with control-meta bits to mean something). This seems simplest and most robust.  Date: 18 March 1981 14:52-EST From: Daniel L. Weinreb To: JERRYB at MIT-AI cc: BUG-NWS at MIT-AI If you want an instance variable to be settable and not gettable, just don't mention it in the DEFFLAVOR, and define your own :SET-FOOBAR message. There's nothing magic about the ones defined automatically by DEFFLAVOR; they are just to save you work in common cases. Your case is not that common.  Date: 18 MAR 1981 1028-EST From: TFT at MIT-AI (Tom Trobaugh) Subject: Scroll bar botheration To: DLW at MIT-AI, TFT at MIT-AI, (BUG ZWEI) at MIT-AI To: (BUG NWS) at MIT-AI Unfortunately, at an earlier setting of these parameters, it because very annoying that it took so much motion to get into the scroll bar, and so I think the buffer zone was reduced at some point. I'm not sure what to do about this. I think it's been moved more than once, because I remember encountering, a year ago or more, the same annoyance I mentioned recently. If you're planning on making this stuff available to "lots" of people, it would seem wise, for the sakes of all concerned, to do some human engineering type research. I presume there's not too much literature on such notions as how wide to make scroll bar regions (you know, it seems that it depends, among other things, on the mass, static frictional coefficient, and dynamic f.c. of the mouse), but you could do some semi-formal experiments on such questions. A bit of a dreary prospect, I suppose, but think of all those future mouse manipulators of the world who stand to benefit. One possibility would be to move scroll bars to the right hand instead of left hand side of windows. Just because Xerox uses the left hand size should not constrain us. I think it is much more likely that users need precision mousing at the left end of a window than at the right end. Unfortunately, it's also more useful to have precision scroll-barring on the left side, for the same reasons. Then again, the importance of precision scroll- barring is not so great.  Date: 17 March 1981 17:19-EST From: Howard I. Cannon Subject: Streams that output to funny places on windows To: RMS at MIT-MC cc: BUG-NWS at MIT-MC I thought about your stream problem some. Though it would be easy to implement the kind of stream that you want, we have not done so as of yet since no one has had a use for them. However, there is a very similar mechanism that might do what you want: You can crate an inferior of the window in question (out of flavor TV:WINDOW, perhaps), and use that to do the otput. If you expose it with the :NOOP option, and :DEEXPOSE it inside a (TV:WITHOUT-SCREEN-MANAGEMENT ...) macro, then you should be able to win. Note that you can make one of these, and set its position as you wish (also inside a TV:WITHOUT-SCREEN-MANAGEMENT). This is both a clean and unclean solution: it's clean as it does what you want, in a modular fashion, and gives you capabilities like seting the font arbitrarily (etc.., after all, that's the modularity). It's unclean because you need to worry about the screen management issues, and because it is probably more mechanism than you want in some cases.  Date: 17 March 1981 17:13-EST From: Mike McMahon Subject: Your bug report of 16-Mar-81 1622-EST To: NEVES at MIT-AI cc: BUG-NWS at MIT-AI First off, i doubt either :DEEXPOSE or :KILL is what you want to do to the window. :DEEXPOSE is usually a no-op since the screen manager will autoexpose the window right away. (i thought the documentation, such as it is, made this quite clear.) :BURY will move it under everything else. :DEACTIVATE will remove it from the "stack" altogether, but not use it up, as would :KILL. Second, your bug is not that :KILL didn't kill the window, it did. It's that you made the window have a totally random superior, one that didn't know anything about having inferiors. So, the bits that it drew when it exposed itself lie around on that superior until you do a refresh, which shows that they really aren't there any more. Use the screen or another frame as the superior for your frame, not a lisp listener or whatever you have been using.  Date: 17 March 1981 17:06-EST From: Howard I. Cannon To: NEVES at MIT-AI cc: BUG-NWS at MIT-AI In your example, the superior of your frame is some completly random window (probably the lisp listener), that doesn't want to have inferiors. What you rally want to do is leave that out, and let the superior default, else choose a sheet that knows about inferiors, like TV:MAIN-SCREEN or COLOR:COLOR-SCREEN. Most likely, you want it to default.  Date: 16 MAR 1981 1955-EST From: JerryB at MIT-AI (Gerald R. Barber) To: (BUG NWS) at MIT-AI In the version of NWS in System 65.18, ZMail 19.2, microcode 739, on Lisp Machine Sixteen: How about [terminal] C complementing the mouse documentation line?  Date: 16 March 1981 19:05-EST From: Jonathan D. Taft To: BUG-NWS at MIT-MC One more vote for using a more readable font in the documentation line. Also, is their any reason CPTFONTB [filename CPTFNB] is not loaded in the initial environment ? MEDFNB [filename MEDFNB] is by the way.  Date: 16 March 1981 18:18-EST From: Robert W. Kerns Subject: Mouse documentation and bucky-mouse To: dlw at MIT-AI cc: BUG-NWS at MIT-AI Date: 16 March 1981 01:12-EST From: Daniel L. Weinreb Subject: Mouse documentation and bucky-mouse To: BUG-NWS at MIT-AI, RWK at MIT-MC One of the reasons for the mouse-prompting line in the first place was to be able to support the "mouse bucky bit" hack in a more reasonable way. I'm very glad to hear that, since I like the feature so much. Once again, thank you! However, that hack has to get integrated into the window system in a better way before it can be released for real use. It must work for a user to be running Daedalus in the top half of his screen and Muzaks in the bottom, and for everything to work right. Rightness includes but is not limited to the criteria that the prompting all gets done in the mouse prompt line, without the two programs getting in each other's way, and that there should not be two different background processes just to watch the "bucky" keys. The exact way to integrate all this is not obvious and has to be designed carefully. That was the purpose of making the BUCKY-MOUSE-BUTTOM-COMMAND-TABLE an instance variable of the window, and the clicks working by sending a message to the apropriate window, etc., as described in my note. The "not limited to" part is why I sent the note. I was looking for the "not obvious" part. Since we are all busy working on other things, it hasn't been done yet. I understand that. As I said, I would be willing to provide some effort on this. Howard and I are going to get together and talk about it. Even if you hadn't been planning to integrating it into the system, I was going to be doing it for Muzacs, and wanted to do it right. When I took the idea from SCHEMA I did some work to make it more modular and exportable. Although I didn't tackle the entire problem, it did come down to only one or two places to change when the next person (I don't remember who it was now) wanted to take the idea from me for some other system. (By the way, I would hate to see anything be installed with the substring "BUCKY" in its name. We have enough incomprehensible jargon around here as it is.) I agree, but I don't know of a substitute name. Date: 14 MAR 1981 0114-EST From: Moon at MIT-AI (David A. Moon) Subject: mouse documentation and bucky bits To: RWK at MIT-MC CC: (BUG NWS) at MIT-AI The mouse documentation window is part of the who-line, and therefore is updated only once a second. If it was done by a process, it would be updated more often with a lot more overhead. We might consider making the scheduler update the who-line more often when it notices that the machine is idle, just as it now does some garbage collection when it notices that the machine is idle. Well, I think it should be updated when it changes. For example, by the :MOUSE-MOVES method for menus, when it finds you're pointing at a different item than before. Then there is no extra overhead. Somebody, like the scheduler or keyboard process, would of course have to notice that they keyboard state has changed. In fact, this brings to mind another gripe I have about mouse handling, namely that it doesn't see mouse-clicks when it's running. I'm continually annoyed at having to re-click on the mouse just because the machine hasn't quite caught up with me. I presume there is some reason for this, but it makes the machine feel unresponsive. Presumably the right way to do things is considerably simpler than what was in your message; the :WHO-LINE-MOUSE-DOCUMENTATION method should do a TV:KEY-STATE and decide which string to return, rather than having an extraneous daemon process which is constantly looking at the keys and changing the string that that method returns. I don't see this as being simpler, or even all that different. SOMEBODY has to notice that the keystate has changed, and a hell of a lot faster than the wholine notices it now! Whether this is a demon process or part of some other process is an efficiency matter, as you suggest above, not a complexity matter. I did not mention the :WHO-LINE-MOUSE-DOCUMENTION method in my note because I wasn't proposing changing that mechanism. I merely documented a way for the user to provide the information necessary to the :WHO-LINE-MOUSE-DOCUMENTATION method. The method itself would have to change, of course. Not mentioning that was an oversight in my message.  Date: 16 March 1981 16:43-EST From: Carl W. Hoffman To: BUG-NWS at MIT-MC, RZ at MIT-MC I also would like to see the mouse documentation line printed using a bold font. I find the mouse line in Daedalus and Muzacs more readable than the line provided by the Lispm, particularly from the EECS machines. Perhaps the CPTFONTB font should be used, or one of the bold Helvetica fonts.  Date: 16 MAR 1981 1622-EST From: NEVES at MIT-AI (David M. Neves) To: (BUG NWS) at MIT-AI I created a frame with two panes and then sent it a :kill message and it did not go away (although the top pane did). i then sent it a :deexpose message and nothing happened. however if i refresh the screen (by sending a :refresh message the frame goes away. How do I get rid of the frame? the text for the incident follows. (defun create-new-window () (tv:window-create 'tv:bordered-constraint-frame-with-shared-io-buffer ':io-buffer (funcall tv:selected-window ':io-buffer) ':edges-from ':mouse ':expose-p t ':save-bits t ':superior tv:selected-window ':panes '((environment tv:window-pane :more-p nil) (typein tv:window-pane :label nil :more-p nil :save-bits t)) ':constraints '((main . ((environment typein) ((typein 5 :lines)) ((environment :even))))))) CREATE-NEW-WINDOW (setq temp (create-new-window)) # (funcall temp ':kill) ;the window is still there # ) (setq temp2 (create-new-window)) # (funcall temp2 ':deexpose) ;the window is still there  Date: 16 MAR 1981 1336-EST From: JerryB at MIT-AI (Gerald R. Barber) To: (BUG NWS) at MIT-AI In the version of NWS in System 65.18, ZMail 19.2, microcode 739, on Lisp Machine Sixteen: Why is there no way to make an instance variable of a flavor settable but not gettable. It seems if there is a gettable-instance-variable option in additon to the settable-instance-variable option the gettable one should overide the (strange, unintuitive) behavior of settable to automatically generate gettables.  Date: 16 March 1981 01:12-EST From: Daniel L. Weinreb Subject: Mouse documentation and bucky-mouse To: BUG-NWS at MIT-AI, RWK at MIT-MC One of the reasons for the mouse-prompting line in the first place was to be able to support the "mouse bucky bit" hack in a more reasonable way. However, that hack has to get integrated into the window system in a better way before it can be released for real use. It must work for a user to be running Daedalus in the top half of his screen and Muzaks in the bottom, and for everything to work right. Rightness includes but is not limited to the criteria that the prompting all gets done in the mouse prompt line, without the two programs getting in each other's way, and that there should not be two different background processes just to watch the "bucky" keys. The exact way to integrate all this is not obvious and has to be designed carefully. Since we are all busy working on other things, it hasn't been done yet. (By the way, I would hate to see anything be installed with the substring "BUCKY" in its name. We have enough incomprehensible jargon around here as it is.)  Date: 15 MAR 1981 0356-EST From: RMS at MIT-AI (Richard M. Stallman) To: (BUG NWS) at MIT-AI I'd like to be able to do some output, involving multiple lines, to a window and have the lines start at a specified hpos other than the left edge of the window. Preferably it would not involve clobbering anything in the window itself even temporarily, so as to avoid interfering with anything else. Is there a way to do this? According to the Interlisp-D book, they could do it by creating a new display stream and setting the slot which controls the hpos to CR to (which is distinct from the clipping edge).  Date: 14 MAR 1981 1149-EST From: BAK at MIT-AI (William A. Kornfeld) Subject: Scroll bar botheration To: (BUG ZWEI) at MIT-AI, (BUG NWS) at MIT-AI I second the motion to put the scroll bar over on the right, at least for the editor. The scroll bar in Zmacs has always caused more pain than convenience. Rightifying it has a good chance of winning.  Date: 14 March 1981 02:55-EST From: Daniel L. Weinreb Subject: Scroll bar botheration To: TFT at MIT-AI, BUG-ZWEI at MIT-AI, BUG-NWS at MIT-AI Unfortunately, at an earlier setting of these parameters, it because very annoying that it took so much motion to get into the scroll bar, and so I think the buffer zone was reduced at some point. I'm not sure what to do about this. One possibility would be to move scroll bars to the right hand instead of left hand side of windows. Just because Xerox uses the left hand size should not constrain us. I think it is much more likely that users need precision mousing at the left end of a window than at the right end. I get the "second scroll bar" too, but as I keep moving left it seems to repeat, going in and out of scroll mode. This is definitely confusing behavior. By the way, folks, one of the reasons that it is painful to get into the scroll region in ZWEI buffers is that if there is a lot of text in the buffer, it has to page in the whole buffer in order to figure out where to display the scroll bar and how tall to make the bar. This paging can take quite a long time and make it really annoying to try to do some scrolling, especially for the usual reason that you are tempted to think that the mouse is stuck.  Date: 14 March 1981 02:43-EST From: Daniel L. Weinreb To: JERRYB at MIT-AI, MMCM at MIT-AI cc: BUG-NWS at MIT-AI Well, that's purely a matter of taste. I find the black bar quite unobtrusive. Didn't HIC's message tell you how to make it white-on-black in your init file?  Date: 14 MAR 1981 0114-EST From: Moon at MIT-AI (David A. Moon) Subject: mouse documentation and bucky bits To: RWK at MIT-MC CC: (BUG NWS) at MIT-AI The mouse documentation window is part of the who-line, and therefore is updated only once a second. If it was done by a process, it would be updated more often with a lot more overhead. We might consider making the scheduler update the who-line more often when it notices that the machine is idle, just as it now does some garbage collection when it notices that the machine is idle. Presumably the right way to do things is considerably simpler than what was in your message; the :WHO-LINE-MOUSE-DOCUMENTATION method should do a TV:KEY-STATE and decide which string to return, rather than having an extraneous daemon process which is constantly looking at the keys and changing the string that that method returns. As you suggest, there should be generalized ways to make things like menus sensitive to bucky bits. Some of the other NWS people probably have some ideas of what the right way to do this stuff is.  Date: 13 March 1981 05:19-EST From: Robert W. Kerns Subject: Mouse documentation and bucky-mouse To: BUG-NWS at MIT-AI There are a number of systems around now which use the bucky-mouse-buttons hack. I think this is worth integrating with the system mouse-documentation bar (which, btw, is an incredibly winning feature for which I cannot thank you enough). We want to do this with Muzacs anyway, and Muzacs already has much of the functionality desired, so I might implement this. I'd be interested in feedback as to just how much of this belongs in the system as well as comments on the details of the scheme. The way I would see this working is something along these lines: * BUCKY-MOUSE-BUTTONS-WINDOW-MIXIN would be the mixin to use to cause a window to have it's mouse-clicks interpreted according to the state of the bucky keys. ** It would cause the window to be sent a :BUCKY-MOUSE-CLICKS message with arguments of the bucky bits and what mouse-button was clicked (and maybe how many times). * BUCKY-MOUSE-BUTTON-COMMANDS-WINDOW-MIXIN would be the mixin to use to keep the mouse documentation window up-to-date according to the state of the bucky keys, and provide dispatching to the commands documented. ** It would provide demons for the :HANDLE-MOUSE message which would activate the bucky-pane process. As in the current bucky schemes, this process is responsible for keeping the documentation strings corresponding with the state of the bucky keys. (BTW, how come the system mouse documentation stuff is so slow? The bucky documentation pane is many times faster.) ** An initable instance variable BUCKY-MOUSE-BUTTON-COMMAND-TABLE. This would give documentation and and what to do for each combination of right/middle/left, buckyness, and once/twice. This would be a 3x16 array (2^4 for hyyper/super/meta/control) of menu-items (:EVAL, :FUNCALL, :NO-SELECT, :WINDOW-OP, :KBD, and :MENU would be the ones likely to be useful) plus items of the form (:FORWARD :HYPER :META :RIGHT) to allow some to default to be the same as others. The :DOCUMENTATION modifier would be highly recommended, as always! ** If different actions are possible according to what is being pointed at, the :HANDLE-MOUSE message would be able to either modify the command table, or swap command tables. If the former, some action would have to be taken to cause the documentation to be updated. If the latter, the bucky process could notice for itself. *** This feature might benifit from making the mouse documentation window 2 lines high, and putting single-click and double-click on separate lines. (I find ZMACS's mouse-documentation line to be hard to read, for example). However, maybe 3x16 is enough mouse buttons, and double buttons should be disallowed in bucky windows. *** It is manually reasonable to extend the hyper/super/meta/control selection to include top/greek/shift, if you do not combine super with top, greek with meta, or shift with control. It is easy to move the finger up a row to get top instead of super, etc. Perhaps the implementation should be 3x128 instead, to allow for people to do this, but not actually make use of top/greek/shift'd mouse keys in the system. ** ZMACS and ZMAIL could both make good use of this feature. For example, if control-mouse-left were DELETE FORWARD, control-mouse-middle were REMOVE, and CONTROL-MOUSE-RIGHT were DELETE REVERSE, the it would be possible to walk through a survey manipulating messages much faster than is currently true, where you have to go through 3 levels of menu to do this for a random message in the survey (right on a message, right on DELETE in the menu that gives you, gives you a menu which provides finally after 3 selections what this scheme gives you in a bucky-shift and a click.) ZMACS could put a lot more commands on the mouse, making many things more convenient. For example, the "Mark thing" and "Save/Kill/Yank" current features could be spread out to give you more control. "Save/Kill/Yank" could be left, middle, and right of one combination of bucky keys, and "Mark thing" could become an entire family. "Mark word" "Mark Sentence" "Mark paragraph" could be one subfamily, "Mark word" "Mark s-expr" "Mark Defun" could be another. Putting more functions on the mouse can also help reduce how much you have to move between the mouse and the keyboard. For example, if the M-./select-with-mouse functionality were provided directly via the mouse, then it would not be necessary for right-handed people to move their right-hand from the "." key to the mouse to select something. You'd just point to the function name with the mouse while holding down some bucky keys with your left hand, click the apropriate button, and viola! And as an added feature: * BUCKY-MOUSE-MENU-MIXIN would be a mixin for menus which creates a menu whose selection of items is selected from a table bucky-states, according to the state of the bucky keys. ** (somewhat random idea, but I might actually use it if it were done) The mouse-documentation-window could be modified to allow it to be pointed to with the mouse, and when so pointed to, could provide fast access to a large number of functions (like many currently in the system menu) via BUCKY-MOUSE-MENU-MIXIN. This makes good use of screen space....  Date: 12 MAR 1981 1206-EST From: JerryB at MIT-AI (Gerald R. Barber) To: (BUG NWS) at MIT-AI In the version of NWS in System 65.18, ZMail 19.2, microcode 739, on Lisp Machine Sixteen: In the inspector, the history pane has no mouse documentation, that is until you go into the scroll bar, then the scroll bar mouse documentation is always around.  Date: 12 MAR 1981 1026-EST From: JerryB at MIT-AI (Gerald R. Barber) To: MMCM at MIT-AI, DLW at MIT-AI CC: (BUG NWS) at MIT-AI Date: 11 March 1981 23:49-EST From: Mike McMahon .... (I did finally verify that it does NOT abort in the case i described.) And inverse video on this monitor sucks too much to be at all legible. I vote that the default for the mouse documentation line not be inverse video. Aside from the readability problem I find that big black bar very annoying. If it is not inverse video and one is not using the mouse there is usually a place on the screen that you can move the mouse where nothing will appear in the documentation window. Thus removing all distraction. In the case when it is inverse video the black bar is always there to distract you.  Date: 12 March 1981 02:55-EST From: Daniel L. Weinreb Subject: Undoability of kill To: MOON at MIT-MC cc: BUG-NWS at MIT-MC Yes, yes, of course Kill is not undoable. I was not complaining that it ought to be undoable. I was complaining that if it is not undoable, then attempting to undo it should cause a feep, not make a half-assed attempt to work.  MOON@MIT-MC 03/11/81 23:21:40 Re: Undoability of kill To: dlw at MIT-AI CC: (BUG NWS) at MIT-MC Date: 11 March 1981 21:48-EST From: Daniel L. Weinreb To: BUG-NWS at MIT-AI In the version of NWS in System 65.16, ZMail 19.2, microcode 739, on Lisp Machine Six: Mouse-prompting claims that Undo doesn't work for the Kill command, but it did work for the case I tried. I assume this refers to the screen editor? You must have tried it on a window whose :kill method does nothing but deactivate the window. Obviously :kill can have side-effects which cannot be undone, such as killing a process, closing a network connection, deleting a file, etc.  Date: 11 March 1981 23:49-EST From: Mike McMahon To: DLW at MIT-AI cc: BUG-NWS at MIT-AI Date: 11 March 1981 22:39-EST From: Daniel L. Weinreb By the way, the fact that clicking middle aborts Move Window is documented in the mouse prompt line. Maybe mouse prompting is useful for experts, too. I know better than to believe everything i read. (I did finally verify that it does NOT abort in the case i described.) And inverse video on this monitor sucks too much to be at all legible.  Date: 11 March 1981 23:41-EST From: Mike McMahon To: DLW at MIT-AI cc: BUG-NWS at MIT-AI Date: 11 March 1981 22:35-EST From: Daniel L. Weinreb Date: 11 March 1981 15:12-EST From: Mike McMahon In the version of NWS in System 65.13, ZMail 19.1, microcode 739, on Lisp Machine Three: Is there no way to abort Move Window in the screen editor? Mouse-middle works fine for me, both when it is asking which window and when it is showing the heavy outline. Mouse-middle is the conventional abort character for the screen editor. The case that failed for me was with ZMail only on the screen, System menu/Right on Edit Screen/ZMail frame/Move Window/Summary window. It may have to do with that window not being very movable. I cannot double check it since this mouse is too spastic to let me click on something in the Edit screen menu without going out of it.  Date: 11 March 1981 22:39-EST From: Daniel L. Weinreb To: MMCM at MIT-AI cc: BUG-NWS at MIT-AI By the way, the fact that clicking middle aborts Move Window is documented in the mouse prompt line. Maybe mouse prompting is useful for experts, too. I notice that when the Screen Editor's Kill command is offering you the confirmation single-item menu, there's nothing in the mouse prompt line. Probably it ought to say things.  Date: 11 March 1981 22:35-EST From: Daniel L. Weinreb To: MMCM at MIT-AI, BUG-NWS at MIT-AI Date: 11 March 1981 15:12-EST From: Mike McMahon To: BUG-NWS at MIT-AI In the version of NWS in System 65.13, ZMail 19.1, microcode 739, on Lisp Machine Three: Is there no way to abort Move Window in the screen editor? Mouse-middle works fine for me, both when it is asking which window and when it is showing the heavy outline. Mouse-middle is the conventional abort character for the screen editor.  Date: 11 March 1981 21:48-EST From: Daniel L. Weinreb To: BUG-NWS at MIT-AI In the version of NWS in System 65.16, ZMail 19.2, microcode 739, on Lisp Machine Six: Mouse-prompting claims that Undo doesn't work for the Kill command, but it did work for the case I tried.  Date: 11 March 1981 15:12-EST From: Mike McMahon To: BUG-NWS at MIT-AI In the version of NWS in System 65.13, ZMail 19.1, microcode 739, on Lisp Machine Three: Is there no way to abort Move Window in the screen editor?  Date: 6 March 1981 20:18-EST From: Mike McMahon To: ZVONA at MIT-AI cc: BUG-NWS at MIT-AI Date: 6 MAR 1981 1857-EST From: Zvona at MIT-AI (David Chapman) In System 65.5, ZMail 19.0, microcode 739, on Lisp Machine Eighteen: The mouse menu is only on in the minibuffer which is sort of weird since that should not have anything to do with mouse commands. It is sort of distracting. I assume what is happening is that the mouse is sitting in the corner, so that the mini-buffer becomes the mouse-window when you use it. That is what is supposed to happen. There is no way to get rid of the mouse entirely.  Date: 5 MAR 1981 0035-EST From: dlw at MIT-AI (Daniel L. Weinreb) To: (BUG NWS) at MIT-AI In System 65.4, ZMail 19.1, microcode 739, on Lisp Machine Nine: In the multiple-choice menu produced by Kill or Save Buffers in Zmacs, there is mouse documentation when the mouse blinker is in the Do It and Abort buttons, but not when the mouse blinker is in the middle of the window.  Date: 4 March 1981 13:37-EST From: Daniel L. Weinreb To: BUG-ZMAIL at MIT-AI cc: BUG-NWS at MIT-AI In the version of ZMAIL in System 65.3, ZMail 19.0, microcode 739, on Lisp Machine Nine: Could the scroll bar in the Zmail summary window be made thicker than one pixel? There's plenty of room out there, and scrolling is one of the main things one does with that window. In fact, maybe the scroll bar for most scrolling windows that aren't used intensively (most things besides editor windows) should have thicker scroll bars. The Zmail summary window might even want to have a scroll bar that is always visible, although people would find that obnoxious.  Date: 3 March 1981 23:09-EST From: Robert W. Kerns To: BUG-NWS at MIT-AI cc: BUG-ZMAIL at MIT-MC In the version of NWS in System 65.1, ZMail 19.0, microcode 739, on Lisp Machine Six: In a ZMAIL frame, in BOTH mode, when the mouse is over the message window, but the window is not selected, the editor mouse-buttons is shown. This isn't right, since mouse left will actually just select that window, and mouse right gets you the system menu.  Date: 3 MAR 1981 2149-EST From: lmwin at MIT-AI (Jean-Paul Fenetre) Subject: That who-line bug To: (BUG NWS) at MIT-AI Well, I ended up patching it after all, since I was making a patch anyway. - Moon  Date: 3 MAR 1981 2027-EST From: Moon at MIT-AI (David A. Moon) Subject: Documentation line of who-line garbage upon booting To: (BUG NWS) at MIT-AI (WHO-LINE-CLOBBERED) does work, it just redisplays too fast to see. Use of the cold-load stream verifies that it works. The problem was that WHO-LINE-DOCUMENTATION-FUNCTION and WHO-LINE-FILE-STATE-FUNCTION didn't know what WHO-LINE-ITEM-STATE being NIL meant. I added comments and fixed the code (also removed some code that didn't do anything while I was at it). I didn't make a patch since it didn't seem important enough to warrant a patch.  Date: 3 MAR 1981 1540-EST From: DLW at MIT-AI (Daniel L. Weinreb) To: (BUG NWS) at MIT-AI I think the tiny descriptions of what the various ABORT and BREAK commands do, that was given in the system release message, are much easier to understand than the ones in the TERMINAL HELP message. What do you think of changing TERMINAL HELP to say what the system release message says?  Date: 2 March 1981 17:27-EST From: Howard I. Cannon To: MMcM at MIT-AI cc: BUG-NWS at MIT-AI Date: 2 March 1981 16:45-EST From: Mike McMahon To: BUG-NWS at MIT-AI In the version of nws in System 64.4, ZMail 18.1, microcode 739, on Lisp Machine Six: The summary window in ZMAIL has :SAVE-BITS ':DELAYED, but the one in this world doesn't have one or any sign of any intentions of getting one ever. I'm gonna work on this.  Date: 2 MAR 1981 1645-EST From: MMcM at MIT-AI (Mike McMahon) To: (BUG NWS) at MIT-AI In the version of nws in System 64.4, ZMail 18.1, microcode 739, on Lisp Machine Six: The summary window in ZMAIL has :SAVE-BITS ':DELAYED, but the one in this world doesn't have one or any sign of any intentions of getting one ever.  Date: 1 March 1981 15:20-EST From: Howard I. Cannon Subject: More bugs due to changing size of screen To: MOON at MIT-MC cc: BUG-NWS at MIT-AI Date: 1 March 1981 01:21-EST From: David A. Moon To: HIC, BUG-NWS at MIT-AI Re: More bugs due to changing size of screen In the version of NWS in System 64.0, ZMail 18.0, microcode 739, on Lisp Machine Six: The m-X View File command in ZMail does not work, because it tries to expose a window which is too big to fit in the zmail frame. The zmail frame is smaller than it was when it was created because the size of the screen was decreased (why the screen wasn't just created with the correct size in the first place is unclear). When the zmail frame was made smaller, it didn't adjust the size of all its inferiors (this one was probably deactivated at the time, and didn't get adjusted when it was activated because for some reasons the code to do that is in a mixin which frames don't have). A) The screen was not created smaller origionally because that would have made turning off the documentation line unbelieveably slow as it would have had to recreate every bit array. B) You are confused about how frames (are supposed to?) work. They don't need the mixin because they change the size of their windows via the configuration mechanism. This works in all cases assuming you use :SET-CONFIGURATION to expose/deexpose panes. I presume that the reason it fails in Zmail is that Zmail just exposes some random window. If this is the case, it better have a :CHANGE-OF-SIZE-OR-MARGINS daemon that does the right thing to its random windows. I assume this bug applies to all frames and not just zmail frames. I doubt it, for the reasons stated above.  Date: 1 March 1981 15:06-EST From: Howard I. Cannon To: MOON at MIT-MC cc: BUG-nws at MIT-AI Date: 03/01/81 01:07:49 From: Moon To: (BUG nws) at MIT-AI In the version of nws in System 64.0, ZMail 18.0, microcode 739, on Lisp Machine Six: Did someone change the list starting with :MENU that COMMAND-MENU-MIXIN forces-kbd-input? EH:PROCESS-SPECIAL-COMMAND (part of the window error handler) broke because it had the wrong idea of the format of this list. It isn't wise to go around changing these things, you know. Don't jump to conclusions. I changed the format of the window error handler's item list to have documentation, and obviously broke something. As far as I know, COMMAND-MENU-MIXIN did not change.  Date: 1 March 1981 15:00-EST From: Howard I. Cannon To: MOON at MIT-MC cc: BUG-NWS at MIT-MC Date: 03/01/81 01:13:37 From: Moon To: (BUG NWS) Why does Terminal Help use WINDOW-MOUSE-CALL and System Help use WINDOW-CALL? The reason Terminal Help didn't do anything until after System Help had been used was because (SELECT-MIXIN :MOUSE-SELECT) had not been updated for this time-stamp nonsense. Patched in 64.1 but this is all totally unmodular. Well, in this case it's mouse-select that's pretty fucked. The reason for the code that checks SHEET-WITHIN-SHEET-P is so that you can click on a window that is active but partially off the screen and not get an error. It's clear that the error check ought to happen at a higher level, or only if the sheet is active. I don't think putting that activate there is the right fix at all. However, I did not change it. I'm not sure what you mean by "but this is all totally unmodular". What's this? If you mean the time-stamp stuff, then yes, it is, and that's why I didn't want to do it that way, except I had to for it to work at all. If you mean selection, that's gonna get fixed soon.  Moon@MIT-MC 03/01/81 02:12:27 Re: incorrect documentation in who-line To: (BUG nws) at MIT-AI In the version of nws in System 64.0, ZMail 18.0, microcode 739, on Lisp Machine Six: Other/Set Mouse Screen claims that the right button always gives a menu. Actually if there is only one screen on the machine it does not give a menu. Margin choices (e.g. in the editor's kill-or-save-buffers display) claim that any button can be clicked to select the choice. Actually the right-button gives a system menu. In this case it is probably the documentation that is correct. In the inspector, when you position the mouse to a scrolling area it tells you what moving it does but not what clicking it does, unless you are scrolled all the way to the end, in which case it tells you that clicking gets the next page, but actually it doesn't do anything except beep. Editor commands that use the mouse in a special way, e.g. meta-., do not update the documentation. Other than these it's pretty good.  Moon@MIT-MC 03/01/81 01:51:05 Re: dont-select-with-mouse-mixin To: MMcM at MIT-AI CC: (BUG NWS) at MIT-AI Date: 26 February 1981 12:51-EST From: Mike McMahon To: BUG-NWS at MIT-AI cc: DEKLEER at PARC-MAXC Date: 25 FEB 1981 1403-PST From: DEKLEER at PARC-MAXC .... If the blinker is blinking in the text pane you can button the minibuffer pane and get the blinker there to blink. Everything still works fine, but you can't invert the operation. You have to use the system menu or go in and out of ZWEI. Of course the echo area window has dont-select-with-mouse-mixin, but that doesn't help for the usual variety of reasons. The actual reason is that dont-select-with-mouse-mixin only redefines :name-for-selection, not :mouse-select, so it has no effect on the behavior of the mouse-select function which appears to be what is used by clicking the mouse on a window. Would it break things to change dont-select-with-mouse-mixin to turn off :mouse-select? That message seems to be used for several things that have little or nothing to do with the mouse. It's a crock anyway that it takes a mixin to turn off selectability by the mouse rather than one to turn it on. I guess select-mixin is the culprit here.  Moon@MIT-MC 03/01/81 01:21:23 Re: More bugs due to changing size of screen To: HIC at MIT-MC, (BUG NWS) at MIT-AI In the version of NWS in System 64.0, ZMail 18.0, microcode 739, on Lisp Machine Six: The m-X View File command in ZMail does not work, because it tries to expose a window which is too big to fit in the zmail frame. The zmail frame is smaller than it was when it was created because the size of the screen was decreased (why the screen wasn't just created with the correct size in the first place is unclear). When the zmail frame was made smaller, it didn't adjust the size of all its inferiors (this one was probably deactivated at the time, and didn't get adjusted when it was activated because for some reasons the code to do that is in a mixin which frames don't have). I assume this bug applies to all frames and not just zmail frames. I don't think this system can be released to users. I have fixed a dozen or so of the other bugs in it, but I don't think I want to try to fix this one.  Moon@MIT-MC 03/01/81 01:13:37 To: (BUG NWS) at MIT-MC Why does Terminal Help use WINDOW-MOUSE-CALL and System Help use WINDOW-CALL? The reason Terminal Help didn't do anything until after System Help had been used was because (SELECT-MIXIN :MOUSE-SELECT) had not been updated for this time-stamp nonsense. Patched in 64.1 but this is all totally unmodular.  Moon@MIT-MC 03/01/81 01:07:49 To: (BUG nws) at MIT-AI In the version of nws in System 64.0, ZMail 18.0, microcode 739, on Lisp Machine Six: Did someone change the list starting with :MENU that COMMAND-MENU-MIXIN forces-kbd-input? EH:PROCESS-SPECIAL-COMMAND (part of the window error handler) broke because it had the wrong idea of the format of this list. It isn't wise to go around changing these things, you know.  Date: 28 FEB 1981 0127-EST From: Moon at MIT-AI (David A. Moon) Sent-by: lispm at MIT-AI To: (BUG NWS) at MIT-AI In System 64.0, ZMail 18.0, microcode 739, on Lisp Machine Six: If you type Terminal Help before the first time you type System Help, then it doesn't do anything. Afterwards it does. I can't see anything different in the window. It doesn't leave a process lying around but trace says kbd-esc-help never returns. Must be magic and self-immolating!  Date: 28 FEB 1981 0000-EST From: mmcm at MIT-AI (Mike McMahon) Sent-by: ___010 at MIT-AI To: (BUG NWS) at MIT-AI Somehow when you cold boot, nothing manages to clear the mouse documentation who-line sheet.  Date: 26 February 1981 12:51-EST From: Mike McMahon To: BUG-NWS at MIT-AI cc: DEKLEER at PARC-MAXC Date: 25 FEB 1981 1403-PST From: DEKLEER at PARC-MAXC In System 59.29, Ether 1.4, microcode 723, (59), on Xerox Machine 2: There is some strangeness going on in selecting between the main text pane and the mini-buffer. Frequently I get myself in a state where everything works but the blinker is blinking in the mini-buffer not the text area. I then get back in a winning state by explicitly selecting the editor window again with the system menu. (This usually happens because the editor got an error in one of my functions (e.g. ethernet) or some form it was evaluating or compiling.) Here are simple cases. If the blinker is blinking in the text pane you can button the minibuffer pane and get the blinker there to blink. Everything still works fine, but you can't invert the operation. You have to use the system menu or go in and out of ZWEI. Of course the echo area window has dont-select-with-mouse-mixin, but that doesn't help for the usual variety of reasons. If you do an incremental search, the blinker blinks in the mini-buffer pane as you want, but if you do a break I'd expect it to select the pane in which the break happens (i.e. what terminal-io gets bound to). A way to screw yourself in this case is to use the system menu to select the text pane. Everything works fine until you do a resume in which case your keystrokes don't seem to go anywhere. There should not be user commands to cause intra-program window selection like this.  Date: 25 FEB 1981 1711-EST From: MMCM at MIT-AI (Mike McMahon) To: (BUG NWS) at MIT-AI If you reshape a dead window error handler (such as by turning on mouse documentation) it can still have its hands on a stack frame for a process that has long since stopped being in error at all. Needless to say this causes a lot of random errors.  Date: 23 FEB 1981 0136-EST From: Moon at MIT-AI (David A. Moon) Subject: Notifications that you don't get to see (second message) To: (BUG NWS) at MIT-AI It seems to happen a lot in Zmail (in system 63) that a notification comes out while I'm switching windows and so I don't get to see it for long enough to read it. If I don't notice the feep I never know it happened. Would it be too gross to lock the window for a few seconds after printing a notification, giving the user time to see it? No, the actual problem is that the window (e.g. a zmacs echo area window) gets deexposed between the time the notification system decides to print on it and the time it actually prints the message. The process that was e.g. trying to type out then hangs forever in output-hold on the window it was trying to print the notification on. I will try and do something about this. Suggestions would be appreciated.  HIC@MIT-MC 02/23/81 01:28:07 To: (BUG NWS) at MIT-MC CC: MMCM at MIT-MC I have started adding one line mouse documentation to the system, since I now have a facility to display it in the wholine. The work is by no means completed (I have done the screen editor, system menu, some of the inspector). It's real easy to do, and I'd like to see it happen to both Zmail and Zmacs, as well as things like the window error handler. I guess I should get together with you and show you what the facility looks like so you can hack the things that only you understand. We should get as much documentation in as possible before we release system 64.  Date: 23 FEB 1981 0127-EST From: Moon at MIT-AI (David A. Moon) Subject: Notifications that you don't get to see To: (BUG NWS) at MIT-AI It seems to happen a lot in Zmail (in system 63) that a notification comes out while I'm switching windows and so I don't get to see it for long enough to read it. If I don't notice the feep I never know it happened. Would it be too gross to lock the window for a few seconds after printing a notification, giving the user time to see it?  Date: 22 FEB 1981 0650-EST From: DLA at MIT-AI (David L. Andre) To: (BUG NWS) at MIT-AI CC: DLA at MIT-EECS In the version of NWS in System 59.29, ZMail 16.3, microcode 731, on Lisp Machine Six: It seems that, when drawing borders with TV:DRAW-RECTANGULAR-BORDERS, the rectangles are drawn in a totally non-symmetric way. To be specific, the left rectangle takes up the entire left side of the screen, the bottom rectangle is "clipped" on both sides, and the right and top rectangles are clipped on one side each. This is fine for rectangles, but for anything else which will probably (1) be wide and (2) have some sort of latteral (correct word?) symmetry. Since you've already gone to so much trouble so that random border drawing functions can be defined, you probably should advertise some symmerty. How about top and bottom take up the whole length of the side, and left and right are clipped? What I specifically had in mind was drawing graduations in the border of a window which draws fields. -- Dave  Date: 21 February 1981 16:33-EST From: Howard I. Cannon Subject: Problem I don't know what to do about To: Moon at MIT-AI cc: BUG-NWS at MIT-AI Yeah, this seems to be a new "manifestation", since I haven't observed it in systems below 63. Does something have to be done about it?  Date: 21 FEB 1981 0545-EST From: Moon at MIT-AI (David A. Moon) Subject: Problem I don't know what to do about To: (BUG NWS) at MIT-AI When you boot, and it does the system initializations, first the process initialization goes off, and this lets some processes start running (some of which are needed to do some of the following initializations, e.g. Chaosnet). Then a while later it does the window initialization. Some processes can run and hack windows before windows are properly initialized. E.g. on a warm-boot I have seen the zmacs windows process wake up and do a redisplay before the initializations complete.  Date: 21 FEB 1981 0432-EST From: Moon at MIT-AI (David A. Moon) Subject: Time wrong in system 63 who line To: (BUG NWS) at MIT-AI Howard should learn to balance his parentheses more carefully  Date: 20 FEB 1981 1650-EST From: DLW at MIT-AI (Daniel L. Weinreb) To: RMS at MIT-AI CC: (BUG NWS) at MIT-AI RMS@MIT-AI 02/20/81 04:18:02 Instaed of (or in addition to) :draw-string, how about a :draw-stream operation that returns a stream that draws on the window with specified cursor, alu-function, etc. This is somewhat like changing the window's alu function, but local. In fact, it is somewhat wrong to associate output cursors, alu-functions, etc. with windows at all. A window is an area of space that can be drawn on, and it makes sense and can be useful to have multiple streams all drawing on the window in different places, using different fonts, etc. The stream object ought to be separate. Some windows should automatically make one stream object and make it be somebody's standard-output; others would not. In any case the user could make more stream objects and they would all be on an equal footing. I don't feel that the way it works now is "wrong"; it is just a simpler functionality than the one you are suggesting. Furthermore, it is very convenient to have the stream and the window be the same object. In the simple case there is only one such stream, and you would have to say "get the window of this stream" in various places to do certain things. From the other side of the issue, MMcM has suggested that draw-string should take sufficient arguments to allow it do draw on diagonals and such, which I agree is useful. We are really talking about a graphics operation here, one that is not stream-like.  Date: 20 FEB 1981 1116-EST From: JerryB at MIT-AI (Gerald R. Barber) To: (BUG NWS) at MIT-AI In the version of NWS in System 59.29, ZMail 16.3, microcode 723, on Lisp Machine Fifteen: It would be really nice if -abort aborted a F instead of restarting it.  Date: 19 February 1981 12:28-EST From: Howard I. Cannon Subject: WHOLIN compilation problem? To: Moon at MIT-AI cc: BUG-NWS at MIT-AI Date: 19 February 1981 06:21-EST From: David A. Moon To: HIC at MIT-AI cc: BUG-NWS at MIT-AI Re: WHOLIN compilation problem? Are MAIN-SCREEN-WIDTH and MAIN-SCREEN-HEIGHT declared somewhere? It got a barf declared special on them, and I have the latest TVDEFS loaded. Is this going to cause an unbound variable error at run time? They are declared and defined in SHWARM. I suppose they should really be in TVDEFS, but I doubt it will cause errors in loading.  Date: 19 FEB 1981 0621-EST From: Moon at MIT-AI (David A. Moon) Subject: WHOLIN compilation problem? To: HIC at MIT-AI CC: (BUG NWS) at MIT-AI Are MAIN-SCREEN-WIDTH and MAIN-SCREEN-HEIGHT declared somewhere? It got a barf declared special on them, and I have the latest TVDEFS loaded. Is this going to cause an unbound variable error at run time?  MOON@MIT-MC 02/19/81 06:11:28 Re: ABORT in EH To: dlw at MIT-AI CC: (BUG NWS) at MIT-AI Date: 19 FEB 1981 0449-EST From: dlw at MIT-AI (Daniel L. Weinreb) To: (BUG NWS) at MIT-AI In the new system, if you are in the error handler and you start typing a form to be evaluated and then you type Abort, the Abort is treated as an alphabetic character (it just echoes). This is because the EH's io-buffer-output-function does not intercept Abort specifically; it sees that Abort is an EH command and so it just returns it. If you change Abort to not be an EH command, the effect is that Abort always gets you back to the command level (with the right-arrow) and Meta-Abort resets the process, thus aborting out of the error handler. I am not sure if this is exactly right but it does seem more consistent with the new definition of Abort and Meta-Abort. It's completely wrong. Like with BREAK, typing ABORT at EH as a command returns to the previous command level. It is necessary to be able to have the ability to return to the previous command level as well as to reset the process. Now that we have an Abort key, it really seems right for that to be used rather than (or in addition to) Control-G. The Control-G character was selected for its purpose long before we had any Abort key. Yes, the bug here is that ABORT doesn't return to the current command level while typing in a form, in EH. That is what ABORT does in BREAK. This should be fixed. Note that ABORT has to be a command in EH rather than just getting the default throwing, because the command does various cleaning up (which I wouldn't swear that I understand the details of). I'll look at this tomorrow or whenever and maybe fix it to work right.  Date: 19 FEB 1981 0449-EST From: dlw at MIT-AI (Daniel L. Weinreb) To: (BUG NWS) at MIT-AI In the new system, if you are in the error handler and you start typing a form to be evaluated and then you type Abort, the Abort is treated as an alphabetic character (it just echoes). This is because the EH's io-buffer-output-function does not intercept Abort specifically; it sees that Abort is an EH command and so it just returns it. If you change Abort to not be an EH command, the effect is that Abort always gets you back to the command level (with the right-arrow) and Meta-Abort resets the process, thus aborting out of the error handler. I am not sure if this is exactly right but it does seem more consistent with the new definition of Abort and Meta-Abort. Now that we have an Abort key, it really seems right for that to be used rather than (or in addition to) Control-G. The Control-G character was selected for its purpose long before we had any Abort key. Opinions?  Date: 19 FEB 1981 0307-EST From: dlw at MIT-AI (Daniel L. Weinreb) Subject: Window system To: DEKLEER at PARC-MAXC, rz at MIT-MC CC: (BUG NWS) at MIT-AI Both of you have asked for ways to change the char-aluf of a window. It seems that what both of you are REALLY trying to do is to type out strings on the window in XOR mode. It would be quite consistent with the philosophy inherent in the present organization of things if we were to add a new message to tv:graphics-mixin called :draw-string. It would take arguments something like (alu-function x y string &optional (from 0) (to nil) (font tv:current-font)) and type a substring of the string at the given position, with the given font and alu-function. (This is not necessarily the actual order of args; I would have to study that further.) The problem with this is that you do not get the feature of having a "cursor" that advances. Is this OK with you? It depends on your application. Would this message be the right thing for what you are trying to do?  Date: 19 FEB 1981 0247-EST From: Moon at MIT-AI (David A. Moon) Subject: Temporary windows To: (BUG NWS) at MIT-AI (SELECT-MIXIN :MOUSE-SELECT) clears temporary locks on the window being selected, but not on any other windows that may need to be deexposed in order to expose that window. This is why terminal-0-S often just hangs.  Date: 18 February 1981 19:26-EST From: Daniel L. Weinreb Subject: [RWG at MIT-MC: Forwarded] To: BUG-NWS at MIT-AI RWG@MIT-MC 02/18/81 05:19:06 To: DLW at MIT-MC from the window EH, is there any way to rectify a too-few-args? i tried set arg, but it didn't update the missing args picture, and wouldn't let me continue.  MOON@MIT-MC 02/18/81 18:29:45 Re: Unfortunateness To: (BUG NWS) at MIT-MC m-x Function Apropos of (I think) SCREEN in the TV package dies with an error in the mouse-sensitive-items facility because it finds a symbol whose pname is longer than the width of the screen. It should do something more reasonable than signal an error.  Date: 18 FEB 1981 0315-EST From: Moon at MIT-AI (David A. Moon) Subject: New notification system To: (BUG NWS) at MIT-AI Is about 2/3 done, but I'm too burned out to continue, will have to finish it tomorrow. I haven't broken any system source files, the incompatible new stuff is all on files on my dir.  Date: 16 FEB 1981 0510-EST From: Moon at MIT-AI (David A. Moon) Subject: Enjoying a good time with your canine companion To: (BUG NWS) at MIT-AI Well, this system 61 seems fairly solid, i.e. I fixed all the bugs that shafted me, with the exception of ztop mode problems that probably aren't new. All files that contain COMPILE-FLAVOR-METHODS should be recompiled in 61.3 before building a new world, as I have fixed what I believe to be all the reasons that compilation of combined methods was occurring at load time, and in the process have made an incompatible internal change which will probably cause most of the old compiled combined methods to be assumed to be bad when they are loaded.  Date: 15 FEB 1981 2226-EST From: Moon at MIT-AI (David A. Moon) Subject: Magnitude of bands To: (BUG NWS) at MIT-AI In the version of NWS in System 61.1, ZMail 17.0, microcode 726, on Lisp Machine Nine: In the initial system there are 27 bit arrays attached to windows (there may be one or two others, e.g. the temporary buffer for the screen manager and the XGP hardcopy one), totalling 400K words, or 1/4 of working-storage-area. 184K of these are associated with Zmail. We could easily buy back 1000 or more pages by making bit arrays not be created until they were first needed, similar to the way temporary bit arrays are handled. Leave T in the slot until the first time the window is de-exposed, at which time allocate a bit array. Before there was a real bit-array, SHEET-FORCE-ACCESS would refrain from accessing its body. Fortunately, the expansion of the SHEET-FORCE-ACCESS macro is compatible; it is the create/expose/deexpose code that sets up the screen-array that would need to changed. This would mean that the first time you entered Peek or Zmail, it would be slower because it would have to allocate an array and draw its label and borders. It seems worth it to me, however.  Date: 13 February 1981 20:12-EST From: Mike McMahon Subject: [tk at MIT-AI: Forwarded] To: BUG-NWS at MIT-AI tk@MIT-AI 02/13/81 19:56:28 In the version of ZMAIL in System 59.25, ZMail 16.3, Daedalus 8.14, microcode 723, on Lisp Machine Two: Annoyance: mouse right on save-files, it pops up a button menu. Said menu is not sensitive to the right mouse button, which instead gives you the system menu.  Date: 12 FEB 1981 1203-EST From: JerryB at MIT-AI (Gerald R. Barber) To: (BUG NWS) at MIT-AI In the version of NWS in System 59.21, ZMail 16.3, microcode 723, on Lisp Machine Fifteen: I received a notification while typing to the minibuffer of a zmacs-frame, the result was a little window with what appeared to be a label: "Notification: NIL" and "Lock" in the who line. Mousing the Notificatiion window unfroze things.  Date: 10 FEB 1981 1704-EST From: dlw at MIT-AI (Daniel L. Weinreb) Subject: Notification To: MOON at MIT-AI CC: (BUG NWS) at MIT-AI This looks good to me. I poked into some of the existing code and it looks like it would all be improved under your scheme. Of course, the new scheme inherits all problems associated with the meaning of "selected window" (will :PRINT-NOTIFICATION get sent to the pane or the frame?) but that is unavoidable for now. I wondered for a while why the default method for :NOTIFY sends :PRINT-NOTIFICATION rather than calling TV:NOTIFY and what the distinction was. I take it there really isn't any distinction in this case; if so it might be clearer to have it call TV:NOTIFY since that is the well-known documented function. The proposed new behavior for pop-up notification sounds like a great improvement.  Date: 10 February 1981 16:25-EST From: Mike McMahon To: BUG-NWS at MIT-AI cc: TK at MIT-AI Date: 10 FEB 1981 0827-EST From: tk at MIT-AI (Tom Knight) In the version of NWS in System 59.3, ZMail 16.2, microcode 723, on Lisp Machine Two: Mouse process calls array-dimension-n with a null array argument bombing to the cold load stream error handler if you mouse right while in the scroll bar of the zmail summary window, as far up in the scroll bar as you can go (into the top margin). This only happens if there is something scrolled above the screen. I fixed this to not bomb out. The scroll window still seems to be full of off-by-one errors. This example now scrolls by one line when it should not scroll at all.  Date: 10 FEB 1981 0827-EST From: tk at MIT-AI (Tom Knight) To: (BUG NWS) at MIT-AI In the version of NWS in System 59.3, ZMail 16.2, microcode 723, on Lisp Machine Two: Mouse process calls array-dimension-n with a null array argument bombing to the cold load stream error handler if you mouse right while in the scroll bar of the zmail summary window, as far up in the scroll bar as you can go (into the top margin). This only happens if there is something scrolled above the screen. If you are already at the top, it beeps. Backtrace is: array-dimension-n tv:scroll-item-lines tv:scroll-find-a-top-item-internal tv:scroll-redisplay-item-loop tv:scroll-find-a-top-item (method tv:basic-scroll-window scroll-relative) (method tv:basic-scroll-bar mouse-buttons-scroll) ... (zwei:zmail-summary-scroll-window handle-mouse)  Date: 10 FEB 1981 0322-EST From: Moon at MIT-AI (David A. Moon) Subject: Notification To: (BUG NWS) at MIT-AI Notification is all screwed up because a lot of things have been added in an ad hoc way; I would like to rethink it and change it around. First we discuss the caller's interface to notification, then worry about problems with pop-up notification windows. This is motivated by the fact that I wanted to make a background process that would occasionally send the user a message and I discovered that there was currently no reasonable way to do this. This is how it works now. There are three messages and two functions. (TV:NOTIFY-USER message window) is one primitive. It is also accessible as (FUNCALL window ':NOTIFY message). message is :ERROR for the error handler, or else a string that plugs into a canned message about processes. window is only used if message is :ERROR, and has to do with errors only wanting to notify if the window is deexposed, whereas other callers of TV:NOTIFY-USER have already decided that they want to notify. You might expect TV:NOTIFY-USER to make its window arg "interesting", i.e. make it available to esc-0-S, but actually some of its callers do that, and in the :ERROR case it makes it available to esc-0-S by a separate mechanism (binding a variable which is looked for via SYMEVAL-IN-STACK-GROUP). The message :NOTIFY-STREAM &optional window-of-interest is how one gets a place to print a notification. The :NOTIFY-STREAM message is the one that things redefine to control whether or not they get pop-up notification windows, etc. This causes lots of problems we have been hearing about lately, because it returns a stream to the caller who can then print an arbitrary message an arbitrary time later, and because it doesn't know about the window-of-interest and making it available to esc-0-S. There is also a function TV:GET-NOTIFICATION-STREAM which is an interface that sends this message to SELECTED-WINDOW. The :NOTIFY-OUTPUT message is another ad hoc kludge. When TV:NOTIFY-USER is about to be called because the deexposed-typeout-action was :NOTIFY, then first this message is sent and if it returns NIL the notification goes through but otherwise it is assumed to have handled it. There is also a "function" TV:MAKE-SELF-INTERESTING which for some reason is a macro. Here's what I would like to replace this with. Here I will ignore compatibility issues and freely reuse the same names with different arguments; if we think it is important we can change the names and make it upward compatible, although probably no users have managed to figure this out and depend on it. There is a function, TV:NOTIFY (FNOTIFY?) which takes arguments of a window-to-make-interesting (which can be NIL if there is none), and then args like format. It works by sending the :PRINT-NOTIFICATION message to the SELECTED-WINDOW with its same arguments. That message either prints the notification or makes a pop-up window and prints it there. Note that the FORMAT string may NOT contain ~& nor ~%. :PRINT-NOTIFICATION is the message which one redefines to control how notifications are printed while one's window (program actually) is selected. This message also takes care of any necessary beeping and of making the window "interesting". There is a second message, :NOTIFY, which is sent to a window when certain interesting events happen to THAT window. It takes one argument which is a SYMBOL defining the event. Known events are :ERROR -- an error occurred and the error message is to be typed out on this window. :OUTPUT -- typeout happened while deexposed and deexposed-typeout-action was :NOTIFY :INPUT -- typein was waited for while deexposed (deselected?) and a (new) deexposed-typein-action flag is set in the window. background-lisp-interactors, which implement this manually now, and the esc-T command will use this flag. The default method for :NOTIFY waits for there to be a selected window, then if this window is exposed, forget the event which is no longer interesting. Otherwise send a :PRINT-NOTIFICATION message to the selected window with an appropriate string and SELF as the window. This is approximately what TV:NOTIFY-USER does now. The :NOTIFY message will use :OR :BASE-FLAVOR-LAST method-combination so that a user who wants to handle certain cases or suppress notifications in some cases can do so by defining a :NOTIFY method that returns non-NIL for the cases it handles. This replaces what (BASIC-NVT :NOTIFY-OUTPUT) does now. Possibly :NOTIFY :ERROR normally returns SELF, and alternatively returns a stream which the error handler should use instead, typically the cold-load stream. Then the default handler for :NOTIFY checks for the window being locked or otherwise broken when the arg is :ERROR. The reason I make this one message with an argument rather than a separate message for each case is partly dumb prejudice against defining infinite messages, but mostly a feeling that the processing for different events will be common in many cases. Pop-up notification windows have the following problems. They make themselves brothers of SELECTED-WINDOW; they can therefore be too small or be an inferior of a window that doesn't want random inferiors. They don't contain any self-documentation and are hard to get rid of. This would be fixed by handling the :PRINT-NOTIFICATION message appropriately and by making it always an inferior of the top-level superior (screen) of the selected-window rather than the immediate superior. A pop-up notification window would display the text of the notification followed by "Type any character to get rid of this notification:" except if there was a window of interest it would also say "or select by typing Terminal-0-S or clicking the mouse here". Typeahead would be treated similarly to qsends (beep, delay, snarf-kbd-input). ----- Please comment. I will refrain from implementing this for a day or two in case someone thinks I am on totally the wrong track.  Date: 6 February 1981 00:57-EST From: Daniel L. Weinreb To: BUG-ZWEI at MIT-AI cc: BUG-NWS at MIT-AI In the version of ZWEI in System 59.3, ZMail 16.2, microcode 723, on Lisp Machine Fifteen: When I am in the minibuffer (say, in c-X B) and I get a notification that my Supdup wants to type out, it appears that what happens is that a little window exactly the shape of the minibuffer, with a label saying "Notification", pops up over the minibuffer, telling me that the Sudup wants to type out. Then the wholine says Output Hold, no blinkers blink, the minibuffer is not visible so I can't click on it, and so there is no obvious easy way to go back to what I was doing and ignore the notification. This is the kind of thing that I belive causes users to say "Every time I use the Lisp Machine for a long time, it freezes up and I have to warm-boot." (I.e., I really would like to see this improved...)  Date: 6 February 1981 00:37-EST From: Daniel L. Weinreb To: BUG-ZMAIL at MIT-AI cc: BUG-NWS at MIT-AI In the version of ZMAIL in System 59.3, ZMail 16.2, microcode 723, on Lisp Machine Fifteen: If a notify-user happens while you are editing a "Send mail to BUG-" window, something very illegible happens. I think it types out the notification on top of what you are editing or something; it was too fast for me to see what was happening.  Moon@MIT-MC 02/05/81 02:25:29 Re: FED of large fonts To: smatt at MIT-AI CC: (BUG NWS) at MIT-AI BEE@MIT-AI 02/01/81 18:54:33 To: (BUG NWS) at MIT-AI From: SMATT FED will not accept characters with large heights (80 pixels). It does take a long time to run. Try smatt;font kst, where the fonts name is musfn1 I hope this helps. feding that font works for me, more or less. You have to use the @ command to set the scale down to where the character fits on the screen, and it is almost unusably slow, and the D command gets an error because the whole font sample doesn't fit on the screen, but it works more or less. Try it in system 59, I fixed some bugs in FED a few weeks ago that might have had to do with large fonts. I think maybe the @ command didn't work until I fixed it.  Date: 4 February 1981 19:32-EST From: Mike McMahon Subject: [JerryB: Forwarded] To: BUG-NWS at MIT-AI Date: 02/04/81 13:55:21 From: JerryB To: (BUG ZMAIL) ... On the question of defaulting mouse buttons. I like the idea but initially found it confusing and think new users would also find it confusing. Generally I use the left button to do most selection operations such as windows, menu items etc. This seems to be a convention (or is my style idiosyncratic?) On the other hand I have come to think of the right button as often doing something which is a variant of the left button but more esoteric. In this vein wouldn't it be better for the left button to consistently offer the most options and information and the right button provide the (more esoteric) defaulting behavior, ie switch the left and right buttons as they are now defined. New users could then depend on using the left button to offer the most options/information.  Date: 3 February 1981 23:09-EST From: Robert W. Kerns Subject: Feature-suggestion To: BUG-ZMAIL at MIT-AI cc: BUG-NWS at MIT-MC In the version of ZMAIL in System 59.2, ZMail 16.1, microcode 723, on Lisp Machine Fifteen: s:F That gubbish on the line above is because I moused the "Headers" window, and immediately started typing. Seeing it go to the wrong place, I went to rub it out, but by that time the selection had occurred, and my rubouts went to the header window. Foo! Anyway, a feature for ZMAIL would be for Mouse Middle in the summary to repeat the last Mouse Right operation. This is more convenient than using Mark Survey and a temporary file and Map Over to accomplish the same result.  Date: 3 February 1981 03:19-EST From: Daniel L. Weinreb To: MMCM at MIT-AI cc: BUG-NWS at MIT-AI Well, I said :ON because the "standard way for blinkers to act" is that they blink when the window is selected and are on without blinking when the window is not selected. This is how Lisp Listeners and editor windows behave. However, maybe what I really mean is that the default visibility for the initial blinker should be :ON, and then if you create other blinkers yourself, they are probably not supposed to blink as well, and so they should have a visibility of T. :BLINK certainly seems wrong.  Date: 2 February 1981 15:36-EST From: Mike McMahon To: DLW at MIT-AI cc: BUG-NWS at MIT-AI Date: 31 JAN 1981 2304-EST From: dlw at MIT-AI (Daniel L. Weinreb) It seems like the default new blinker-visibility when you create a blinker ought to be :on rather than :blink, since :on is basically the "normal thing" that we usually use. HIC suggests I change it. Does anything know of anything that would break if I did so? Do you really mean :ON and not T? Of course things would break, but not very many.  Date: 2 February 1981 13:10-EST From: Mike McMahon To: BUG-NWS at MIT-AI cc: DLW at MIT-AI Date: 2 February 1981 02:31-EST From: Daniel L. Weinreb In the version of ZMAIL in System 57.4, ZMail 15.1, microcode 720, New QCP1, on Lisp Machine Six: It appears that this new ZMAIL does not show you user notifications. My Supdup tried to tell me that it wanted to type out, while I was in ZMAIL, and what happened is that I heard a feep but saw no message. The second line of the bottom pane was empty. I imagine this is the same problem with editors with only two lines at the bottom. The notification stuff terpri's after it is done, erasing what it just printed. I think things might work better if the selected window were sent the notification itself rather than a request for a stream onto which to print it. Then lisp listeners could terpri.  Date: 31 January 1981 23:11-EST From: Daniel L. Weinreb Subject: WINDOC To: MOON at MIT-AI cc: BUG-NWS at MIT-AI I've changed it to say "ready to be exposed". I seem to have been confused; :permit allows typeout if the window itself has a bit-array. I've fixed this. Well, the document already does compare :permit with sheet-force-access to some extent. I am not sure I know all the issues anyway. If someone wants to improve what it says now, go ahead. I've changed the description of the screen manager background process; someone should check the text near the .defspec tv:delayihg-screen-management and check it out. I still don't know what user features the screen manager has that should be documented. The bottom-limit arg is not accepted by the :compute-motion message anyway, so I just won't mention it. OK, I documented the :keyboard option in *escape-keys* saying that you should never use it. Strange thing to do but I see your reason. No, I was right, the :left init options are in terms of outside coordinates. This seems wrong to me, too, but I will document it as it is ("I calls em like I sees em.").  Date: 31 JAN 1981 2304-EST From: dlw at MIT-AI (Daniel L. Weinreb) To: (BUG NWS) at MIT-AI It seems like the default new blinker-visibility when you create a blinker ought to be :on rather than :blink, since :on is basically the "normal thing" that we usually use. HIC suggests I change it. Does anything know of anything that would break if I did so?  Date: 30 January 1981 20:49-EST From: Daniel L. Weinreb To: BUG-NWS at MIT-AI cc: JERRYB at MIT-AI Type then space. The window takes about 5 seconds to go away. Fixed in patch 56.41 (yes, I know it has to be patched in system 57 too). The problem was that System Help was doing input without remembering to set kbd-esc-time to nil first, and so nothing happened until the automatic timeout allowed the keyboard process to run. I glanced around for other bugs of this sort and didn't notice any.  Date: 30 JAN 1981 1339-EST From: gjc at MIT-AI (George J. Carrette) To: (BUG NWS) at MIT-AI In the version of NWS in System 56.39, ZMail 14.7, microcode 720, on Lisp Machine Thirteen: Was replying to a qSend from RG, and did an ESC-1-F, typed a afterwards, returning to the qSend window. However the cursor was frozen black (not blinking), type-in was causing TYI-RUN transitions in the wholine, but wasn't doing anything else visible. Mousing to ZMAIL and then Mousing back to the qSend got things unwedged.  Date: 30 January 1981 03:49-EST From: Daniel L. Weinreb To: BUG-NWS at MIT-AI cc: JERRYB at MIT-AI In the version of NWS in System 56.38, ZMail 14.7, microcode 720, on Lisp Machine One: Type then space. The window takes about 5 seconds to go away. It happens for me too, though only sometimes (it usually does). I glanced at the code and don't see any obvious explanation. Doing a Terminal-Break shows (after you forced it to show you by manually clearing the locks, since the whole screen is covered with a temp window!) that it is in the process-wait inside sheet-deexpose, waiting for the mouse process to notice the reconsideration. Could this be a scheduler problem? Could a noticable amount of other NWS slowness be due to our very granular process swiching's making interactions with the mouse process be a bottleneck?  Date: 29 JAN 1981 0505-EST From: Moon at MIT-AI (David A. Moon) Sent-by: LMWIN at MIT-AI Subject: Bugs in window error handler To: (BUG NWS) at MIT-AI In the version of nws in System 56.39, ZMail 14.7, microcode 720, on Lisp Machine Six: It didn't get updated for the Abort/Z changes to the regular error handler. I fixed that much in the source. When you scroll the locals/specials window so that only specials are present, the label still says "locals". I already fixed this once long ago, I don't know why it broke again. When the display is updated by scrolling, the global value of PACKAGE is used instead of the one in the stack-group being examined. Presumably lots of other variables such as BASE lose also. When I esc-breaked out of a compilation, the special variables for COMPILE-STREAM were displayed as part of QC-FILE's frame. I'm too burned out to look into this now, but perhaps I'll look into it tomorrow.  Date: 28 JAN 1981 1744-EST From: JerryB at MIT-AI (Gerald R. Barber) To: (BUG NWS) at MIT-AI In the version of NWS in System 56.38, ZMail 14.7, microcode 720, on Lisp Machine One: This is a bug with choosing configurations in a constraint frame. To change from a configuration A to another configuration B when the SELECTED-PANE is not in B you apparently must go through the following somewhat painful procedure: a. set SELECTED-PANE to NIL. b. choose the new configuration with SET-CONGIFURATION. c. set SELECTED-PANE to the desired pane. But this doesn't work because c results in a "pane not in this frame" error becuase it is checking for it to be on the EXPOSED-INFERIORS list and it isn't there. I changed the SELECT-PANE message to look at the EXPOSED-PANES list on a suggestion by MMcM and this seemed to work but I don't know if it is right. Note that in doing so I had to define the message with the BASIC-CONSTRAINT-FRAME flavor because BASIC-FRAME (where the SELECT-PANE message that caused the problem in c came from) doesn't have EXPOSED-PANES.  Date: 28 JAN 1981 1413-EST From: dlw at MIT-AI (Daniel L. Weinreb) Subject: System-E To: DLA at MIT-AI CC: (BUG NWS) at MIT-AI I have installed a fix to the problem wherein System-E while you have the editor selected creates a new one. The fix is in patch 56.39.  Date: 28 January 1981 13:59-EST From: Mike McMahon To: RWK at MIT-MC cc: BUG-NWS at MIT-MC Date: 28 January 1981 07:22-EST From: Robert W. Kerns When I type R, and I get a notification from SUPDUP while it is in the middle of switching (before actually switching visibly) to the REPLY window, it goes into the LOCK state on the modeline. Also, while I was editing the header for this bug message, I got a SUPDUP notification, which exactly covered my header window. I didn't want to hack with it, so I clicked on the main message window. But the notification window stayed. It went away when I clicked on the modeline instead. I don't know what the right thing is here, but this isn't optimal. In general, I'd prefer that notifications in ZMAIL be less intrusive. Perhaps they could just be a small message on the mode line? The next version of ZMAIL will have several lines at the bottom like the editor.  Date: 28 January 1981 13:55-EST From: Mike McMahon Subject: [JerryB at MIT-AI: Forwarded] To: BUG-NWS at MIT-AI JerryB@MIT-AI 01/28/81 09:32:21 To: (BUG ZMAIL) at MIT-AI In the version of ZMAIL in System 56.38, ZMail 14.7, microcode 720, on Lisp Machine One: If the little information window is showing saying something like "New Mail at...", type 1f. The window pops up but TYI is in the wholine and nothing is typed out. Typing space causes "Lock" to appear in the wholine. cuases the window to disappear, zmail to gobble the space and the window to reappear finally dispaying who is on the lisp machines.  Date: 28 JAN 1981 0948-EST From: JerryB at MIT-AI (Gerald R. Barber) To: (BUG NWS) at MIT-AI In the version of NWS in System 56.38, ZMail 14.7, microcode 720, on Lisp Machine One: Type then space. The window takes about 5 seconds to go away.  Date: 28 January 1981 07:22-EST From: Robert W. Kerns Subject: DEADLOCK! To: BUG-ZMAIL at MIT-AI cc: BUG-NWS at MIT-MC In the version of ZMAIL in System 56.38, ZMail 14.7, microcode 720, on Lisp Machine Fifteen: When I type R, and I get a notification from SUPDUP while it is in the middle of switching (before actually switching visibly) to the REPLY window, it goes into the LOCK state on the modeline. Also, while I was editing the header for this bug message, I got a SUPDUP notification, which exactly covered my header window. I didn't want to hack with it, so I clicked on the main message window. But the notification window stayed. It went away when I clicked on the modeline instead. I don't know what the right thing is here, but this isn't optimal. In general, I'd prefer that notifications in ZMAIL be less intrusive. Perhaps they could just be a small message on the mode line?  Date: 27 January 1981 17:11-EST From: Daniel L. Weinreb To: JERRYB at MIT-AI, BUG-NWS at MIT-AI After doing an (inspect ) -Z works to get back to the lisp-listener but does not. Fixed and patched.  Date: 27 JAN 1981 0953-EST From: JerryB at MIT-AI (Gerald R. Barber) To: (BUG NWS) at MIT-AI In the version of NWS in System 56.35, ZMail 14.7, microcode 720, on Lisp Machine One: After doing an (inspect ) -Z works to get back to the lisp-listener but does not.  Date: 26 January 1981 12:31-EST From: Mike McMahon Subject: [JerryB at MIT-AI: Forwarded] To: BUG-NWS at MIT-AI JerryB@MIT-AI 01/24/81 16:47:55 To: (BUG ZMAIL) at MIT-AI In the version of ZMAIL in System 56.30, ZMail 14.5, microcode 720, on Lisp Machine Four: After sending some mail, do s, the supdup window will appear and then zmail will appear. In this case maybe zmail should not select itself if it is not the selected process?  Date: 26 January 1981 12:26-EST From: Mike McMahon Subject: WINDOC To: DLW at MIT-AI cc: BUG-NWS at MIT-AI Date: 26 January 1981 01:42-EST From: Daniel L. Weinreb Where I say :permit only allows typeout if the superior has a screen array, you wrote "Really? Why should this have any effect?" I don't know why, I just document things. But it really does work that way. I had some discussions with MMcM a while ago about this, mainly because it seems kludgey, and I proposed some sort of change, but HIC was away at SDRC so nothing happened. Maybe I should try to reconstruct this proposal. Some confusion here. The behaviour which i recall giving you trouble is that you can always type out if you superior has a screen array, but if you have one yourself, you need :permit. The proposed change was to have a bit that controlled whether to output hold your inferiors when you are deexposed, preventing typeout by an inferior on a deexposed superior. This bit would default on except for some class of frames to prevent breaking existing code. The comment about not knowing what the bottom-limit argument to :compute-motion does is taken from your STREAM > documentation. I don't know what it does either. Does anybody know? It controlls where wraparound occurs. It is used internally by the editor. I had not realized that there was meant to be a user-visible distinction between blinker visibilities of t and :on. Exactly what is the difference? Is it that :on and :off are overwritten with :blink when the window is selected, but the others are not affected by selection? That's right.  Date: 26 JAN 1981 0428-EST From: Moon at MIT-AI (David A. Moon) Subject: WINDOC To: DLW at MIT-AI CC: (BUG NWS) at MIT-AI Date: 26 January 1981 01:42-EST From: Daniel L. Weinreb Subject: WINDOC To: MOON at MIT-AI cc: BUG-NWS at MIT-AI You point out that a window that is active could be said to be "trying to be exposed". That's a good point. What do you think of my changing all uses of "trying" to "ready", so that the phrase would be "ready to be exposed"? This isn't really perfect either, but it may be less open to misinterpretation. MUCH better! Where I say :permit only allows typeout if the superior has a screen array, you wrote "Really? Why should this have any effect?" I don't know why, I just document things. But it really does work that way. I had some discussions with MMcM a while ago about this, mainly because it seems kludgey, and I proposed some sort of change, but HIC was away at SDRC so nothing happened. Maybe I should try to reconstruct this proposal. I see no reason for :permit to care about that, if there is one it might be nice to know what it is. You say I should explain :permit in terms of sheet-force-access. What?? Do you mean I should contrast when you should use one and when the other? It doesn't make sense to explain :permit in terms of sheet-force-access; they do not work the same way at all, and really have nothing to do with each other. I'm not sure I was the one that wrote that comment, however it seems reasonable. They are two different ways of saying "if the thing isn't visible, write in its bit save array for the future when it becomes visible". Naturally they aren't the same, but comparing and contrasting them seems like a useful way to clarify both of them and their own interactions with whether or not the superior has a screen array and so forth. You say it is possible to make the screen manager display parts of partially-buried windows that do not have bit-save arrays, if they tell it to. Is there a mixin that can be used to make this happen? Is it ever useful? If there is such a mixin then I should mention it in the appropriate place in the subsection about the screen manager. Look for screen-manage-deexposed-visibility, I forget if it is an init option, a message, or a mixin. Probably all three. I guess I still don't understand when the screen manager background process gets used. You say it is used when you throw through a delaying-screen-management, but delaying-screen-management appears to have an unwind-protect handler that calls screen-manager-dequeue-entries or something, which looks like even when there is a throw, the main process does the management. Exactly when DOES the background process do its thing? This macro's been changed since I last saw it, and it appears to have been changed incompetently. On normal exit, it does screen management unless a lock is locked in which case it lets the background process do it. On abnormal exit, it waits for the lock if it is locked. This appears to be backwards. Anyway the background process doesn't run at all during normal operation; it is there to clean up if someone exits abnormally, and to do bring up bits of partially-visible windows when that feature is used. What is probably going in here is that there are a bunch of patches to the original algorithm intended to decrease the chance that screen management will not take place; I guess the idea is that if a window gets deexposed while there is pending screen management on it its bits will get saved with the "wrong" picture in them. Someone (i.e. Howard) needs to take a close look at this. Would someone please tell me all of the interesting things that you can get the screen manager to do for you? What are the random variables that you can set to get it to do things? (Don't tell me about what the various messages do; they are too advanced for this document.) I don't understand the screen manager at that level; you can look for defvar's in the code as well as I can I expect. In response to your question: no, (tv:stream-mixin :clear-char) does not take an optional argument, but the internal function that does all its work does take such an arg. I have upgraded tv:stream-mixin to accept the argument and pass it along. I have no real opinion about whether the flavor name in .defmethod should be in the bold font. If anyone else cares, say something... That's right, there isn't any :set-vsp message. Someone ought to put one in and tell me about it, although it doesn't sound like the most useful thing in the whole world. The comment about not knowing what the bottom-limit argument to :compute-motion does is taken from your STREAM > documentation. I don't know what it does either. Does anybody know? Well, should we document the :keyboard option for tv:*escape-keys*? The argument for not documenting it is that no user should use it, since the benefit is tiny and the possibility of clobbering the keyboard process is great. Opinions? If we don't document why you shouldn't use it Jerry Barber will use it. But maybe he will anyway. Actually I using him as a scapegoat, he isn't the only one. I had not realized that there was meant to be a user-visible distinction between blinker visibilities of t and :on. Exactly what is the difference? Is it that :on and :off are overwritten with :blink when the window is selected, but the others are not affected by selection? Is that false? Is there any other difference? As I understand it :on and :off are remembering the extra bit that this blinker is supposed to blink when the window is selected. Someone who knows for sure should answer this. I never liked doing it this way. Dave noted that list-mouse-buttons-mixin makes a blip with a car of :mouse-buttons, but that mouse-or-kbd-tyi in list-tyi-mixin is set up to check for the car of the blip being :mouse. This really should be fixed. In the :left and :edges options and friends, positions are relative to the OUTSIDE edges of the superior, right? I don't think so, isn't it the case that a window cannot have inferiors in its margins (I know the who-line is an exception to this, also Howard said he was going to change the who-line to not be an inferior of the screen, but to be a separate screen, which would fix some problems.) Did you mean to imply that the :integral-p init-option hacks the right margin? It doesn't; all it does is to possibly increase the bottom margin. I didn't. Maybe I noticed that it would be reasonable for it to be redefined to do so. But not very important.  Date: 26 January 1981 01:42-EST From: Daniel L. Weinreb Subject: WINDOC To: MOON at MIT-AI cc: BUG-NWS at MIT-AI You point out that a window that is active could be said to be "trying to be exposed". That's a good point. What do you think of my changing all uses of "trying" to "ready", so that the phrase would be "ready to be exposed"? This isn't really perfect either, but it may be less open to misinterpretation. Where I say :permit only allows typeout if the superior has a screen array, you wrote "Really? Why should this have any effect?" I don't know why, I just document things. But it really does work that way. I had some discussions with MMcM a while ago about this, mainly because it seems kludgey, and I proposed some sort of change, but HIC was away at SDRC so nothing happened. Maybe I should try to reconstruct this proposal. You say I should explain :permit in terms of sheet-force-access. What?? Do you mean I should contrast when you should use one and when the other? It doesn't make sense to explain :permit in terms of sheet-force-access; they do not work the same way at all, and really have nothing to do with each other. You say it is possible to make the screen manager display parts of partially-buried windows that do not have bit-save arrays, if they tell it to. Is there a mixin that can be used to make this happen? Is it ever useful? If there is such a mixin then I should mention it in the appropriate place in the subsection about the screen manager. I guess I still don't understand when the screen manager background process gets used. You say it is used when you throw through a delaying-screen-management, but delaying-screen-management appears to have an unwind-protect handler that calls screen-manager-dequeue-entries or something, which looks like even when there is a throw, the main process does the management. Exactly when DOES the background process do its thing? Would someone please tell me all of the interesting things that you can get the screen manager to do for you? What are the random variables that you can set to get it to do things? (Don't tell me about what the various messages do; they are too advanced for this document.) In response to your question: no, (tv:stream-mixin :clear-char) does not take an optional argument, but the internal function that does all its work does take such an arg. I have upgraded tv:stream-mixin to accept the argument and pass it along. I have no real opinion about whether the flavor name in .defmethod should be in the bold font. If anyone else cares, say something... That's right, there isn't any :set-vsp message. Someone ought to put one in and tell me about it, although it doesn't sound like the most useful thing in the whole world. The comment about not knowing what the bottom-limit argument to :compute-motion does is taken from your STREAM > documentation. I don't know what it does either. Does anybody know? Well, should we document the :keyboard option for tv:*escape-keys*? The argument for not documenting it is that no user should use it, since the benefit is tiny and the possibility of clobbering the keyboard process is great. Opinions? I had not realized that there was meant to be a user-visible distinction between blinker visibilities of t and :on. Exactly what is the difference? Is it that :on and :off are overwritten with :blink when the window is selected, but the others are not affected by selection? Is that false? Is there any other difference? Dave noted that list-mouse-buttons-mixin makes a blip with a car of :mouse-buttons, but that mouse-or-kbd-tyi in list-tyi-mixin is set up to check for the car of the blip being :mouse. This really should be fixed. In the :left and :edges options and friends, positions are relative to the OUTSIDE edges of the superior, right? Did you mean to imply that the :integral-p init-option hacks the right margin? It doesn't; all it does is to possibly increase the bottom margin.  Date: 26 January 1981 01:35-EST From: Howard I. Cannon To: Moon at MIT-AI cc: BUG-NWS at MIT-AI, DLW at MIT-AI It's one of the crockish attempts at solving the selecetion-versus-frames problem. I don't think I could explain what it does without reading the code first. But it should be flushed soon. Yes, I think it was put in essentailly for Moon's drawing program (CHEWWAX?). Howard, Mike, are you working on the final solution to this suite of problems? Yes, however, the 3 of us (MMCM, MOON, myself (DLW if he wishes)) should get together early next week and physche it out.  Date: 25 JAN 1981 2315-EST From: Moon at MIT-AI (David A. Moon) To: DLW at MIT-AI CC: (BUG NWS) at MIT-AI Date: 25 January 1981 22:06-EST From: Daniel L. Weinreb To: BUG-NWS at MIT-AI In the version of NWS in System 56.30, ZMail 14.5, microcode 720, on Lisp Machine Two: Why is it that the constraint-frame has the constraint-frame-forwarding-mixin, but the constraint-frame-with-shared-io-buffer doesn't? I don't even understand what the effect of using this mixin is. It's one of the crockish attempts at solving the selecetion-versus-frames problem. I don't think I could explain what it does without reading the code first. But it should be flushed soon. Howard, Mike, are you working on the final solution to this suite of problems?  Date: 25 January 1981 22:06-EST From: Daniel L. Weinreb To: BUG-NWS at MIT-AI In the version of NWS in System 56.30, ZMail 14.5, microcode 720, on Lisp Machine Two: Why is it that the constraint-frame has the constraint-frame-forwarding-mixin, but the constraint-frame-with-shared-io-buffer doesn't? I don't even understand what the effect of using this mixin is.  Date: 25 January 1981 20:20-EST From: Daniel L. Weinreb To: BUG-NWS at MIT-AI In the version of NWS in System 56.30, ZMail 14.5, microcode 720, on Lisp Machine Two: I have the idea that there used to be a standard flavor called tv:window-pane, which was a tv:window with tv:pane-mixin. There does not seem to be one in this version of the system. This is a very useful flavor, and having it around makes the window document a bit easier to write. Can this be reinstated (or instated for the first time, if my memory is not as good as pale ink)?  Date: 23 January 1981 20:18-EST From: Mike McMahon To: RMS at MIT-AI cc: BUG-NWS at MIT-AI RMS@MIT-AI 01/23/81 18:00:27 I did C-Z in ZWEI while the compilation had just about finished reading in the input file. It put me in a full screen lisp listener which I supposed was the original one, and it was waiting for input, and there was no activity in the run bar and no file output listed in the who line. SO I am pretty sure that the compilation was aborted. Also, there was no output on the screen. Is it possible that it sent me to some other lisp listener? But that would not explain the lack of activity in the run bar. It was most likely another lisp listener, especially if there was no output on the screen, since there is nothing that flushes that. If you had never done (ed), but only system-e, than tv:idle-lisp-listener would have decided you didn't want the initial lisp listener. I can only guess that your compilations were hung in output hold. Perhaps they got a directory full error trying to open the output file or something like that.  RWK@MIT-MC 01/23/81 17:56:38 To: MOON at MIT-MC, (BUG NWS) at MIT-MC I really didn't expect terminal-0-s to do anything, but I tried anyway because I wanted to know who had it locked, and it was the only random (very) thing I could think of to try. Perhaps there should be a TERMINAL-CONTROL-L command which prints (to the cold load stream if necessary) what window is locking what window according to the LOCK in the wholine?  MOON@MIT-MC 01/23/81 17:53:15 To: RWK at MIT-MC CC: (BUG NWS) at MIT-MC RWK@MIT-MC 01/23/81 09:49:15 To: (BUG LISPM) at MIT-AI In System 56.27, ZMail 14.5, microcode 720, on Lisp Machine Nine: I was in ZMAIL. I did TERMINAL-2-S. It said TYI for a while, so I typed SPACE. It immediately said LOCK. TERMINAL-0-S of course hung my keyboard process. That 30 second timeout there should be documented, it will save people a lot of warm booting, although I doubt it's the right solution to the problem it addresses. What 30 second timeout? I think there's a 5-second timeout after which it assumes the previous terminal/system command is hung and doesn't wait for it to complete before doing the next one. By the way, what did you expect terminal-0-s to do at that point? Anyway the symptom is caused by the zmail pop-up notification window which I think is going to be flushed. I presume you're not interested in the bizzarre behaviour that resulted after I did TERMINAL-CONTROL-CLEAR.  Date: 22 JAN 1981 0323-EST From: Moon at MIT-AI (David A. Moon) To: (BUG NWS) at MIT-AI In the version of NWS in System 56.16, ZMail 14.2, microcode 720, on Lisp Machine Six: There is still a bug by which zmail's pop-up-notification temporary window can be left locked by a process-run-function process which has finished. I don't know how many times that process has been reused since it locked the lock, so I don't know just what it was doing when it forgot to unlock it, but I would guess that it was esc-S'ing to or from the zmail frame.  dlw@MIT-MC 01/21/81 01:33:15 Re: Other>Kill To: (BUG NWS) at MIT-MC In the version of NWS in System 55.18, ZMail 10.2, microcode 715, on Lisp Machine Two: I had two problems trying to use the System_menu>Other>Kill. First, when I did it over a ZMACS frame, it offered to kill the particular pane it was on, rather than the frame itself. Secondly, when it popped up the little one-item confirmation menu, it positioned the cursor in such a way that it was NOT on top of the one and only item of the menu. (I think this is because it is putting you at the center of the window rather than at the center of the inside of the window, and so the presence of the label is messing up the computation.)  Date: 18 January 1981 12:02-EST From: Daniel L. Weinreb To: BUG-NWS at MIT-AI cc: BSG at MIT-AI The following is a long message that attempts to develop some ideas for a more coherent user interface to the Lisp Machine. I start with a piece of mail that stimulated some of these ideas. RMS@MIT-AI 01/17/81 12:03:43 To: MOON at MIT-AI, DLW at MIT-AI My most frequent use of System L is in the editor after compiling something. Now that I've discovered that it is asynchronous, I am afraid to do it before the compilation is finished because then I might end up trying the function before it is finished recompiling. I would rather have the computer do the waiting, so that I could type ahead. I like deferred call on ITS also. I would be satisfied to have some modifier on System make it synchronous, but although you have described instances where asynchronous ones are useful it is not yet clear which one is useful more often (and probably most of the time it makes no difference) so it might still be better to make it compatible with Abort and Break. Perhaps now is time to start polling the users. This, and Dave's recent suggestion that c-X 4 L get a ZTOP in the other window, and some discussions I have been in recently where the use of BREAK inside the editor was discussed, all lead me to belive that we have a basic problem in our paradigm of how the user interacts with the Editor and Lisp to write and modify programs. My feeling about the System key is that it switches you between Systems; between unrelated asynchronous tasks that you are doing. Switching between the Editor and Lisp by using the System key does not fall into this model; here, you are doing ONE sequential task, namely, going through a Lisp debugging loop. In the original (two years ago) model, the idea would be that the Editor and Lisp ought to be in the same "job". Switching between different parts of a job would generally be done with keyboard-synchronous commands, whereas switching between jobs would be done asynchronously. The main objection I have had in the past to the use of the BREAK key is that it invokes a Lisp Listener using a stack-like paradigm: you CALL Lisp, it remembers that it was in the middle of editing, and then you RETURN from Lisp and it goes back to what it had been doing. Since I have become fond of the stackless program-switching provided by the System key, I felt this return to the stack-like paradigm was a step backwards. However, in light of the above distinction between "real" system switching, and editor/lisp-listener switching, I now feel that my criticism was misplaced. Real system switching should be stackless: you should just have these windows that represent "jobs" and the System key should switch between them. But switching between the editor and the Lisp listener is not the same thing; you do them synchronously, both for the mundane reason that you want your compilation finished before you start using the function, and for the more abstract reason that you are doing something time-sequential (for example, there is data-dependency between testing a function and compiling it), and so it makes sense for the commands to come in a single stream. I think that by generalizing things to the great extent we have, and by flushing the concept of "job" from the system, we have made the system harder to use and understand. People are continually confused when they come upon Lisp Listener windows that are just sitting there but not listening to their input buffers (for example, when (inspect) has been done, or the listener is being analyzed by a window error handler). These things are genuinely confusing; it is unreasonable to say "well, you should read the documentation and then you'll understand better". That the inspector window created by (inspect) and the window error handler window created by c-m-W are totally independent windows, not tied to the window from which they came (from the user's point of view) in any way, ends up making the system harder to understand. I would like to see the system reorganized to meet the following goals. The way you use the Lisp Machine is that, at any time, you have one or more jobs (tasks, interactive subsystems). The System and Terminal-S commands are used to move you between jobs, and they are asynchronous (at least by default). Same with the mouse. Jobs should basically correspond with windows (usually frames, presumably) on a one-to-one basis. This is particularly easy to understand, and anything else is generally not that easy to understand. (You can't follow this dicipline completely if your program uses more than one screen.) There should be different flavors of job for doing different things, such as processing mail. One flavor should be for Lisp program development. (Perhaps not for that exclusively, but there should be one that we tell people to use when they want to develop programs.) It should include, within itself, a way to go through the entire debugging loop, including testing the program. Of course, all Lisp Listening should provide editing capability (some form of editor-top-level). (The whole paradigm of the debugging loop should also be improved by the Interlisp File Package ideas, which may be relevant to this discsussion; this has been discussed before and is in the works currently.) Going into the inspector within a process, or into window error handler, should be in the same job, and this should be obvious from the screen. It should not be possible (at least by default) to use System to select the Lisp Listener that is currently paralyzed. I have not figured out further details yet; I'd like to know if people think this might be a reasonable direction to take. Please try to see things from the point of view of non-sophisticated users. I don't think we should be aiming for a "hacker system" that only experts can use. Any opinions?  HIC@MIT-MC 01/17/81 11:49:09 To: MMcM at MIT-AI CC: (BUG NWS) at MIT-AI Date: 12 January 1981 16:03-EST From: Mike McMahon To: BUG-NWS at MIT-AI Date: 9 JAN 1981 2226-EST From: DLA at MIT-AI (David L. Andre) After typing Break, type something like ... and type Clear, and then Abort. The text will only redisplay to the defun line. STREAM-MIXIN-RUBOUT-HANDLER does not send any messages from which the typeout window could deduce that the cursor is being moved up. STREAM-MIXIN-RUBOUT-HANDLER now uses message passing! It sort of sucks that things call random internal functions. I think a pass through the window system is in order to fix as much of this as possible. This function used function calls for about 50% of the work it did. I fixed this, and now it seems to interact correctly with typeout windows.  Date: 16 JAN 1981 0125-EST From: RWK at MIT-AI (Robert W. Kerns) To: (BUG NWS) at MIT-AI In the version of NWS in System 55.17, ZMail 10.1, microcode 715, on Lisp Machine Nine: Go into the window error handler, mouse INSPECT, and type (FOO) or some other undefined function, and it goes into catatonia with TYI on the wholine and the listener window's blinker still blinking.  Date: 14 January 1981 02:35-EST From: Daniel L. Weinreb To: BUG-NWS at MIT-AI In the version of NWS in System 55.17, ZMail 10.2, microcode 715, on Lisp Machine Sixteen: There is one Zmail window and one Supdup window in existence, both full sized. I am typing at Zmail, when suddenly I am notified by a notification window that my Supdup process is trying to type out. So I type Terminal 0 S to select it. I interact with it for a while and then type Terminal S to get back to Zmail. But nothing happens.  Date: 12 JAN 1981 2334-EST From: MMcM at MIT-AI (Mike McMahon) To: MOON at MIT-AI CC: (BUG NWS) at MIT-AI Date: 12 JAN 1981 2250-EST From: Moon at MIT-AI (David A. Moon) Why are there bands, e.g. this one, floating around with no NWATCH warm initialization? Probably because NWATCH deletes its initialization if it cannot get the time and ai and mc happened to be down as that was being saved out.  Date: 12 JAN 1981 2256-EST From: Moon at MIT-AI (David A. Moon) To: (BUG NWS) at MIT-AI In the version of NWS in System 55.17, ZMail 10.1, microcode 715, on Lisp Machine Seven: tv:set-tv-speed crashes the machine irrecoverably. Someone with two working machines should figure out why.  Date: 12 JAN 1981 2250-EST From: Moon at MIT-AI (David A. Moon) To: (BUG NWS) at MIT-AI In the version of NWS in System 55.17, ZMail 10.1, microcode 715, on Lisp Machine Seven: Why are there bands, e.g. this one, floating around with no NWATCH warm initialization?  Date: 12 JAN 1981 1603-EST From: MMcM at MIT-AI (Mike McMahon) To: (BUG NWS) at MIT-AI Date: 9 JAN 1981 2226-EST From: DLA at MIT-AI (David L. Andre) After typing Break, type something like ... and type Clear, and then Abort. The text will only redisplay to the defun line. STREAM-MIXIN-RUBOUT-HANDLER does not send any messages from which the typeout window could deduce that the cursor is being moved up.  HIC@MIT-MC 01/11/81 08:46:38 To: (BUG NWS) at MIT-MC In the version of NWS in System 55.14, ZMail 10.0, microcode 715, on Lisp Machine Six: TURD ALERT!! ARGGGHH!! Type in the following form: (defun x () (process-run-function "Foo" #'(lambda () (y-or-n-p "This is a test")))) Then, type (X). It will notfy you that someone wants to type. Type Esc-0-S to select the window. 50% of the time there will be a blinker turd at the start of the line, as well as one when you stupidly answer Yes to its question (or no, I suppose). I am completely stumpified. I tried for about an hour to find the problem, to no avail. Help me, I think I'm sinking...  HIC@MIT-MC 01/10/81 06:09:27 To: (BUG NWS) at MIT-MC I just rehacked (SHEET :EXPOSE) and (SHEET :DEEXPOSE) to be much better about going blocked with a lock locked (in fact, they won't, unless a caller has a lock locked). This has removed at least one known deadly embrace, and I'm sure has fixed many others. Unfortunatly, this required redefining wrappers for both of these messages. This means that all of the combined methods in files are now obsolete, and that the system won't notice it! So, we have to find each file that uses COMPILE-FLAVOR-METHODS on anything built on top of SHEET, and recompile that file. This includes user's files. THIS SUCKS. I think it's about time we store some sort of hashcode with the wrappers (or, the text of the wrappers themselves), and then do comparisons when a compiled combined method is loaded. In any case, I'd like to encourage a new world-load to get made with this new stuff as soon as we can.  Moon@MIT-MC 01/07/81 22:56:53 Re: Brother-in-law of select/frame problem To: (BUG NWS) at MIT-MC The :BURY message should be split into two. When sent to a pane, one of them buries the pane within its frame, while the other buries the frame. To observe a case where the lack of this does something surprising, put a Supdup in a Split Screen frame (along with, say, an editor) and type NETWORK L. If we had a TERMINAL B command that buried the selected window it would be even worse.  Date: 6 January 1981 17:42-EST From: John L. Kulp Subject: Split screen user interface To: Moon at MIT-AI cc: BUG-NWS at MIT-MC The point is I want to reexpose the whole frame at once. Clearly, it is a loss to have to select each pane individually. Now I know about Layouts, but I think it loses to have separate mechanisms specifying selection of individual windows vs layouts vs frames (there is none at all for frames). I guess what I am asking for is that rather than having the relatively simple feature which just allows you to expose individual windows, the standard select command in the system menu should be a more general thing. I don't yet have a good suggestion of how to offer this to the user.  Date: 4 JAN 1981 1735-EST From: DLA at MIT-AI (David L. Andre) To: (BUG NWS) at MIT-AI CC: DLA at MIT-EECS I received a QSEND just as I was going into the editor. The Qsend flashed onto the screen, and then my own process exposed the editor. Not realizing exactly what happened, I went into a breakpoint and did (print-sends) to get the message. The next message which came notified me that I had a message waiting for the qsend window, and I had to expose the window with the mouse and go from there. Granted, everything worked as advertised, but wouldn't it be better if somehow the QSEND inhibited all other screen hacking until it deexposed itself? -- Dave  Moon@MIT-AI (Sent by Moon at CADR6@MIT-AI) 01/03/81 22:03:46 Re: Split screen user interface To: JLK at MIT-MC CC: (BUG NWS) at MIT-MC JLK@MIT-MC 01/03/81 12:11:31 Re: Split screen user interface To: (BUG NWS) at MIT-MC When I opt for putting my panes in a frame, shouldn't the frame be selectable some how by the SELECT menu or something (in addition to the SYSTEM key option). If the panes are selectable they appear in the select menu. Also, if I tell it to put the frame on some SYSTEM key shouldn't it ask for a confirmation if I already have something on that key (in case I inadvertantly smash some existing useful function). Hmm, maybe.  JLK@MIT-MC 01/03/81 12:11:31 Re: Split screen user interface To: (BUG NWS) at MIT-MC When I opt for putting my panes in a frame, shouldn't the frame be selectable some how by the SELECT menu or something (in addition to the SYSTEM key option). Also, if I tell it to put the frame on some SYSTEM key shouldn't it ask for a confirmation if I already have something on that key (in case I inadvertantly smash some existing useful function). By the way, I was fairly impressed when I created a second split screen configuration where one of the windows was part of a pre-existing configuration, that the window can up instantly (i.e. it was evidently clever enough to notice that the window was already the right thing).  Date: 2 January 1981 22:27-EST From: Daniel L. Weinreb Sender: dlw at CADR2 at MIT-AI To: HIC at MIT-MC, BUG-NWS at MIT-MC Regarding your new feature for letting menus be moved around: presumably this is only for pop-up menus. Is it actually useful for momentary menus? After all, all you are going to do is make a choice and go away. I guess you might want to see something that is currently under the window, in order to make your choice. The main problem is that some pop-up menus, like the system menu, don't have any label, and the borders are so tiny that it would be pretty hard to aim for them. It seems gratuitous to have to put labels on all menus just for this, but I can't think of any other way to make the feature uniformly accessible except to change the basic user interface somehow. Does it work on multiple choice windows and choose variable value windows? (The "right" think might be to use a regular screen editor when you want to move menus, although that is rather a lot of clicks to get to; it would work uniformly for all kinds of windows.)  Date: 2 January 1981 16:05-EST From: Daniel L. Weinreb Sender: dlw at CADR2 at MIT-AI To: RMS at MIT-AI, BUG-NWS at MIT-AI The reason that border specifications work the way they do is that the border margin width (the white space betweeen the borders and the inside of the window) can be specified separately from the width of the borders themselves. There are two widths you can set and so there are two numbers to set, one for each width. This seems simpler than having you set two numbers, one of which is the border margin width and one of which is the sum of the two numbers.  Date: 2 January 1981 08:13-EST From: Bruce E. Edwards Sender: BEE at CADR6 at MIT-AI Subject: Border width To: BUG-NWS at MIT-AI Perhaps it would be more intuitive if :SET-BORDERS argument included the one dot of whitespace inside the box. So the default would be 2 rather than 1 to do the same thing it does now. Setting it to 1 would flush the box, and setting it to 0 would flush the whole border. NIL could mean the same as 0. I think that this is good user interface also.  Date: 2 JAN 1981 0537-EST From: RMS at MIT-AI (Richard M. Stallman) To: (BUG NWS) at MIT-AI Perhaps it would be more intuitive if :SET-BORDERS argument included the one dot of whitespace inside the box. So the default would be 2 rather than 1 to do the same thing it does now. Setting it to 1 would flush the box, and setting it to 0 would flush the whole border. NIL could mean the same as 0. Aside from making 0 do the expected thing, it is just as reasonable for the argument to mean "the width of the whole border" as "the width of the black line".  HIC@MIT-MC (Sent by HIC at CADR7@MIT-MC) 12/31/80 23:20:00 To: CWH at MIT-MC CC: (BUG NWS) at MIT-MC CWH@MIT-MC (Sent by BMT at CADR15@MIT-MC) 12/31/80 16:27:43 To: (BUG NWS) at MIT-MC In the version of NWS in System 53.31, ZMail 8.6, microcode 707, on Lisp Machine Fifteen: After receiving an interactive message, answer "y" to the "Reply?" query. Then decide not to send the message after all, so press . The mode line says "STOP" and nobody listens to the keyboard. Fixed and patched.  CWH@MIT-MC (Sent by BMT at CADR15@MIT-MC) 12/31/80 16:27:43 To: (BUG NWS) at MIT-MC In the version of NWS in System 53.31, ZMail 8.6, microcode 707, on Lisp Machine Fifteen: After receiving an interactive message, answer "y" to the "Reply?" query. Then decide not to send the message after all, so press . The mode line says "STOP" and nobody listens to the keyboard.  Date: 30 DEC 1980 1551-EST From: Moon at MIT-AI (David A. Moon) Sent-by: Moon at CADR6 at MIT-AI Subject: Move Multiple To: ACW at MIT-AI CC: (BUG NWS) at MIT-AI Date: 30 DEC 1980 0733-EST From: ACW at MIT-AI (Allan C. Wechsler) Subject: Move Multiple To: (BUG NWS) at MIT-AI Does anyone remember why the long activation click also interacts with the set of features to be moved? This has always seemed unnatural to me. I would rather click on all the things I want to move, and *then* say, "Hokay, let's do that thing." At present, I have to click on all but one of the features-to-be-moved, and then say, "All right, let's go... and oh, by the way, drag that along too." Click Right to say "do it". The long "click left" is so that you can both select a feature and say do it, if you know it's the last feature (e.g. you're only moving one). It is less useful now that Move Single exists (it didn't originally).  Date: 30 DEC 1980 0733-EST From: ACW at MIT-AI (Allan C. Wechsler) Subject: Move Multiple To: (BUG NWS) at MIT-AI Does anyone remember why the long activation click also interacts with the set of features to be moved? This has always seemed unnatural to me. I would rather click on all the things I want to move, and *then* say, "Hokay, let's do that thing." At present, I have to click on all but one of the features-to-be-moved, and then say, "All right, let's go... and oh, by the way, drag that along too." ---Wechsler  HIC@MIT-MC 12/30/80 04:39:09 To: (BUG NWS) at MIT-MC I implemented a frob that let's you click in the inactive areas of a menu (like the in label or on the borders) and get a little rectangle that let's you move the menu around. This is partially in response to RWG's request, and partially in response to a desire for such a feature. I'd like to here what people think about this. I put it on the middle button, so it shouldn't accidentally get in the way. This probably should be on all temporary window's in some form or another.  HIC@MIT-MC 12/30/80 04:31:05 Re: Yech! To: (BUG NWS) at MIT-MC I just typed in the following code: (LOCAL-DECLARE ((SPECIAL BORDER-MARGIN-WIDTH)) (DEFMETHOD (TOP-BOX-LABEL-MIXIN :AFTER :DRAW-LABEL) (SPEC LEFT TOP RIGHT BOTTOM) SPEC TOP (AND (BOUNDP 'BORDER-MARGIN-WIDTH) ;; DWIM (SETQ LEFT (- LEFT BORDER-MARGIN-WIDTH) RIGHT (+ RIGHT BORDER-MARGIN-WIDTH))) (SHEET-FORCE-ACCESS (SELF) (%DRAW-RECTANGLE (- RIGHT LEFT) 1 LEFT (1- BOTTOM) CHAR-ALUF SELF)))) This was an attempt to get rid of that annoying pixel between the line below the label in a menu and the left and right borders. Notice, that I couldn't see the code I typed due to my "kludge proff goggles". Since I couldn't see the code, I was amazed that it worked, but I still deleted it out of respect to the stomachs of others. What's the right way to do this? If there isn't any, we should install some right way. Perhaps TOP-BOX-LABEL-MIXIN wants to go OUTSIDE of the standard borders, and draw: xxxxxxxxxxxxx x label x x x ??  Moon@MIT-AI (Sent by Moon at CADR6@MIT-AI) 12/30/80 00:36:33 Re: Screen editor bugs To: cwh at MIT-MC CC: (BUG NWS) at MIT-MC cwh@MIT-MC (Sent by cwh at CADR15@MIT-MC) 12/24/80 20:08:49 To: (BUG NWS) at MIT-MC In the version of NWS in System 53.27, ZMail 8.6, microcode 707, on Lisp Machine Fifteen: .... I have fixed all the bugs you reported (except the one that was a bug in you, where you hadn't thrown out an obsolete piece of documentation).  Date: 30 DEC 1980 0034-EST From: Moon at MIT-AI (David A. Moon) Subject: Multiple Move command in Screen Editor To: (BUG NWS) at MIT-AI I see now what Dan was complaining about with the selection of both sides of an edge being confusing. Selecting both sides of an edge is the right thing, but then when you click again and it selects only one side, the problem is that what it does is unselect the one you are pointing at, leaving the one you AREN'T pointing at selected. This is consistent with the way it works in general, but is confusing; it seems more natural to leave the one you are pointing at selected. Maybe this should be changed?  HIC@MIT-MC (Sent by HIC at CADR16@MIT-MC) 12/27/80 23:41:19 To: DLA at MIT-AI CC: (BUG NWS) at MIT-AI Date: 13 December 1980 16:15-EST From: David L. Andre To: BUG-NWS at MIT-AI cc: DLA at MIT-EECS In figuring out margins and borders, I was typing to the initial-lisp-listener things such as: (FUNCALL TV:SELECTED-WINDOW ':SET-BORDERS 5) It seems that the intuitive way to get back to no borders is to: (FUNCALL TV:SELECTED-WINDOW ':SET-BORDERS 0) but in fact, this blows up the screen, then proceeds to pretend that the border width was 1. The "right" thing to do is (FUNCALL TV:SELECTED-WINDOW ':SET-BORDERS NIL). Could 0 and NIL be parsed the same here? -- Dave You can now set the borders to 0. This means something subtly different than setting them to NIL, though. NIL means no borders at all, including the one pixel of whitespace that nromally goes between the border and the inside of the window. 0 means that the width of the BLACK line should be 0, but that the whitespace is still to be there. You can also now specify the list (left-width top-width right-width bottom-width) where the widths can individually be 0, NIL, or > 0, which mean the same as specifying just the number.  Date: 27 December 1980 20:52-EST From: Daniel L. Weinreb Sender: dlw at CADR9 at MIT-AI To: HIC at MIT-MC cc: BUG-NWS at MIT-AI The bug (manifested in editing the Zmacs pane) is gone now. In its place is a milder bug; when you use "Expose (menu)" to expose one of the panes, the name you are prompted with in the menu is not the same as the name showing on the label of the pane. The menu says "BUFFER-n" and the label says "ZMACS-WINDOW-PANE-m".  HIC@MIT-MC (Sent by HIC at CADR16@MIT-MC) 12/27/80 20:25:21 To: dlw at MIT-AI CC: (BUG NWS) at MIT-AI Date: 22 November 1980 02:36-EST From: Daniel L. Weinreb Sender: dlw at CADR1 at MIT-AI To: BUG-NWS at MIT-AI In the version of NWS in System 49.12, ZMail 3.5, microcode 697, on LISP Machine One: This bug is quite reproducible, but I am not sure I can give instructions. What I do is to go into the screen editor on a zmacs pane, Move Single the (one) window's bottom to get it out of the way (move it up), create a second window in the bottom half of the pane, then create a third, smaller window on top of the second window. The second window disappears, as you would expect. Then I use "Expose (menu)". It gives me a menu of one item, the second window. I click it. Nothing happens. I can demo this for anyone who wants, if the instructions above are too vague. I cannot reproduce this but in system 53.29. Perhaps it has been fixed, or perhaps I am doing it wrong. Could you try it in this system and let me know.  HIC@MIT-MC (Sent by HIC at CADR6@MIT-MC) 12/27/80 03:14:26 To: DLW at MIT-AI CC: (BUG NWS) at MIT-AI Date: 26 DEC 1980 2330-EST From: DLW at MIT-AI (Daniel L. Weinreb) To: HIC at MIT-MC CC: (BUG NWS) at MIT-AI What I want it to do is to jump the mouse to the right screen, temporarily, so that I can specify the size and position of the window. Then it should return the mouse to where it was. I suppose this is not the most simple possible thing, but I don't see how it could confuse anyone, and if you don't do things this way I don't see any other reasonable behavior. This is, in spirit and probably in fact, a with-mouse-grabbed, and as long as the mouse is in the "grabbed" state and so not being sensitive to what is under it, I don't think it can hurt to move it to the right screen. OK, it now does what you want. I fixed a bug or two in the mouse code while I was at it. The new behaviour is this: the mouse gets set to the superior of the window you are creating when it prompts you for the corners. Therefore, you will only be able to specify a valid size and position for the window. When it changes the mouse sheet, if the new mouse sheet is directly related to the old one (by the SHEET-ME-OR-MY-KID-P relationship), then the mouse is kept as close to where it used to be as possible. If the old and new mouse sheets are not related, then the mouse gets put in the MIDDLE of the new sheet (this is a change from the old behaviour). No one noticed the old behaviour, though, due to a bug in the mouse sheet changing code, which has been fixed. I didn't bother making a patch.  HIC@MIT-MC (Sent by HIC at CADR6@MIT-MC) 12/27/80 00:34:35 To: DANIEL at MIT-AI CC: (BUG NWS) at MIT-AI Date: 26 December 1980 22:58-EST From: Daniel Weise Sender: DANIEL at CADR2 at MIT-AI To: BUG-NWS at MIT-AI In the version of NWS in System 53.27, ZMail 8.6, Daedalus 5.2, microcode 707, on LISP Machine Two: More processing slightly wedged. It --mores-- AFTER printing the first character on the last line. My way of reproducing this error is to print a VERY big bignum and watch how the more processing handles it. I think this is a manisfestation of an irksome bug that has been bothering me with more processing: When you type on the last line and it wants to do more processing, it will type --more-- after you type char on the last line, eat the next char for the --more--, put the first char at the top of the screen, then typein proceeds normally. However, rubout handling in this state loses badly -- the top line gets erased, the cursor to the correct column, but at the end of the screen, and the typein is not typed out anywhere. This was caused by improper checking of output exceptions by a low-level system function (SHEET-CLEAR-EOL). I've made it check for the **MORE** exception, and this seems to fix the obvious manisfestations of your reported bug. I couldn't reproduce the typing-in-the-number bug. Let me know if it happens again after you load the patch.  Date: 26 DEC 1980 2330-EST From: DLW at MIT-AI (Daniel L. Weinreb) To: HIC at MIT-MC CC: (BUG NWS) at MIT-AI What I want it to do is to jump the mouse to the right screen, temporarily, so that I can specify the size and position of the window. Then it should return the mouse to where it was. I suppose this is not the most simple possible thing, but I don't see how it could confuse anyone, and if you don't do things this way I don't see any other reasonable behavior. This is, in spirit and probably in fact, a with-mouse-grabbed, and as long as the mouse is in the "grabbed" state and so not being sensitive to what is under it, I don't think it can hurt to move it to the right screen.  Date: 26 DEC 1980 2258-EST From: DANIEL at MIT-AI (Daniel Weise) Sent-by: DANIEL at CADR2 at MIT-AI To: (BUG NWS) at MIT-AI In the version of NWS in System 53.27, ZMail 8.6, Daedalus 5.2, microcode 707, on LISP Machine Two: More processing slightly wedged. It --mores-- AFTER printing the first character on the last line. My way of reproducing this error is to print a VERY big bignum and watch how the more processing handles it. I think this is a manisfestation of an irksome bug that has been bothering me with more processing: When you type on the last line and it wants to do more processing, it will type --more-- after you type char on the last line, eat the next char for the --more--, put the first char at the top of the screen, then typein proceeds normally. However, rubout handling in this state loses badly -- the top line gets erased, the cursor to the correct column, but at the end of the screen, and the typein is not typed out anywhere.  MOON@MIT-MC 12/26/80 22:13:53 To: CWH at MIT-MC CC: (BUG nws) at MIT-AI cwh@MIT-MC (Sent by cwh at CADR15@MIT-MC) 12/24/80 20:08:49 To: (BUG NWS) at MIT-MC In the version of NWS in System 53.27, ZMail 8.6, microcode 707, on Lisp Machine Fifteen: In the screen editor: LMWIND;OPERAT 31 claims that for the "Move Multiple" option , clicking middle or right will abort the move and leave all features where they were originally. I find that only middle does this. Yes, it was changed after that version of the documentation was written. The current documentation is correct. After selecting the "Move Window" option, and then selecting a window, there is now way to abort the move. All three buttons cause the window to be moved. Hmm, the middle and right buttons are supposed to work, this must be a bug.  HIC@MIT-MC (Sent by HIC at CADR6@MIT-MC) 12/26/80 20:21:31 To: dlw at MIT-AI CC: (BUG NWS) at MIT-AI Date: 26 December 1980 18:40-EST From: Daniel L. Weinreb Sender: dlw at CADR9 at MIT-AI To: HIC at MIT-MC cc: BUG-NWS at MIT-AI In what way does it "bomb out"? I don't remember; the letter to which you are replying was sent three months ago. The intention of :edges-from ':mouse is that the edges come from the mouse. This doesn't imply that the mouse gets moved anywhere just because the window you are creating happens to be somewhere else. Perhaps there should be another option, but ':mouse should do the simplest thing. Really. What is the simplest thing? That is, if I run a program that creates a window on the color screen and uses :edges-from ':mouse, and moving the mouse over to the color screen is undesirable because it is too complex, what simple thing would be an improvement? Well, it seems clear that the simplest thing, when viewed at that level, is to not put the mouse anywhere. On the other hand, I observed that it does make some effort to relocate the coordinates if you create a window with edges from the mouse whose superior is not the mouse-sheet. I suppose you would like it to set the mouse sheet to be the specified superior in all cases?  Date: 26 December 1980 18:40-EST From: Daniel L. Weinreb Sender: dlw at CADR9 at MIT-AI To: HIC at MIT-MC cc: BUG-NWS at MIT-AI In what way does it "bomb out"? I don't remember; the letter to which you are replying was sent three months ago. The intention of :edges-from ':mouse is that the edges come from the mouse. This doesn't imply that the mouse gets moved anywhere just because the window you are creating happens to be somewhere else. Perhaps there should be another option, but ':mouse should do the simplest thing. Really. What is the simplest thing? That is, if I run a program that creates a window on the color screen and uses :edges-from ':mouse, and moving the mouse over to the color screen is undesirable because it is too complex, what simple thing would be an improvement?  HIC@MIT-MC (Sent by HIC at CADR9@MIT-MC) 12/24/80 23:46:23 To: dlw at MIT-AI CC: (BUG NWS) at MIT-AI Date: 23 October 1980 16:12-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 46.1, with microcode 692, on LISP Machine Eight: There is a real problem in the way scroll bars work now. The problem is that the non-simple geometry is an excellent mimic of the mouse's principle failure mode. When you try to get into a scroll bar, you don't get any feedback telling you that you are on your way, and, as a result, you (well, I do, at least) assume that the mouse is slipping, and you start banging it against the table and getting frustrated. The non-simple geometry is a good idea, but it just does not make it in the current system. It is mostly on the way out that this happens. I just tweaked the scroll bar parameters some. In the next system, when you are in the scroll bar, the mouse will move in a region 15 pixels wide (0 is the left edge of the window, increasing to the right). Also, once you get into the scroll bar, it ignores the speed of the mouse. It will also take fewer pixels of motion to leave the scroll bar. Let's see if it works better.  HIC@MIT-MC (Sent by HIC at CADR9@MIT-MC) 12/24/80 21:20:33 To: Moon at MIT-AI CC: (BUG NWS) at MIT-AI Date: 1 August 1980 23:34-EDT From: 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? Esc-C-Clr now tries to get rid of temporary windows first.  HIC@MIT-MC (Sent by HIC at CADR9@MIT-MC) 12/24/80 21:07:35 To: dlw at MIT-AI CC: (BUG NWS) at MIT-AI Date: 5 October 1980 19:33-EDT From: Daniel L. Weinreb When you create a window on the color screen, and give :edges-from ':mouse, and the mouse is on the main screen, it seems to bomb out. It should move the mouse to the color screen for the duration and work properly. In what way does it "bomb out"? The intention of :edges-from ':mouse is that the edges come from the mouse. This doesn't imply that the mouse gets moved anywhere just because the window you are creating happens to be somewhere else. Perhaps there should be another option, but ':mouse should do the simplest thing (I can actually think of uses for not moving the mouse, so I'm not just arguing for the way it is on the basis of inertia). The Color Window option of the Other Menu moves the mouse to the color screen, for example.  cwh@MIT-MC (Sent by cwh at CADR15@MIT-MC) 12/24/80 20:08:49 To: (BUG NWS) at MIT-MC In the version of NWS in System 53.27, ZMail 8.6, microcode 707, on Lisp Machine Fifteen: In the screen editor: LMWIND;OPERAT 31 claims that for the "Move Multiple" option , clicking middle or right will abort the move and leave all features where they were originally. I find that only middle does this. After selecting the "Move Window" option, and then selecting a window, there is now way to abort the move. All three buttons cause the window to be moved. Enter the inspector, and then invoke the screen editor on the inspector frame. Select the "Move Multiple" option, and then position the mouse on the line separating the bottom two windows. Move above the line and click left a few times. Then move below the line and click left a few more times. The manner in which the features are highlighted seems somewhat confusing. [Just before typing this, I did System I to go to the inspector so I'd have a crop of windows to edit. Then I did System M to get back to add more to this note. I could type into the buffer, but the cursor wasn't blinking. I clicked left and then it started to blink.] When doing "Move Single" or "Move Multiple" and the move blinker is positioned over a portion of the screen where there is no window at all, the blinker disappears and nothing at all tracks the mouse. A little confusing. Caveat: I am pretty burnt out now, so don't take what appears above as being carefully researched.  HIC@MIT-MC (Sent by HIC at CADR6@MIT-MC) 12/24/80 01:54:11 To: CPR at MIT-AI CC: (BUG NWS) at MIT-AI Date: 20 December 1980 17:51-EST From: Christopher P. Ryland Sender: CPR at CADR10 at MIT-AI To: BUG-NWS at MIT-AI In the version of NWS in System 51.3, ZMail 6.0, microcode 705, on LISP Machine Ten: I received a QSend whilst SUPDUPing, replied to it, used ESC ? (old keyboard) in a vain attempt to remember what END maps to on old keyboards, type a space to clear the documentation, and was thrown for a sec back to the supdup window, and then left back at the lisp listener whence I called up supdup. Odd... This bug was caused by some combination of temporary windows. Both QSEND and the pop-up help window are temporary. It has been fixed in the source. Note to BUG-NWS: The fix required rearrangement of the code in the macros WINDOW-SELECT and WINDOW-MOUSE-SELECT. The change should only have a noticeable difference when dealing with temporary windows. Note that all temporary windows selected with either of these macros should be either deexposed or deactivated by the disposition argument else potential deadlock situations may arise.  HIC@MIT-MC (Sent by HIC at CADR9@MIT-MC) 12/23/80 15:37:16 Re: That locking problem in (SHEET :EXPOSE) we discussed at dinner To: Moon at MIT-AI, mmcm at MIT-AI CC: (BUG NWS) at MIT-AI Date: 23 December 1980 01:55-EST From: David A. Moon Subject: That locking problem in (SHEET :EXPOSE) we discussed at dinner To: HIC at MIT-AI cc: BUG-NWS at MIT-AI The issue is that it has ITSELF locked through all of this procedure; actually each time it un-inhibits scheduling and goes to wait for something, it should unlock itself, and then re-lock itself before turning scheduling back off. Yes, that's the right approach. Is there any reason the window needs to be locked around all the daemons? The only daemon I see that really cares is (ESSENTIAL-ACTIVATE :BEFORE :EXPOSE). I guess if you want to be 100% sure about him, then where it says (GO MAIN-LOOP) now it really should be a throw to a catch in the wrapper which then does the whole operation over again. Personally I would rather just flush ESSENTIAL-ACTIVATE and build it into SHEET, it is already in all but name. Yes, I like the *THROW idea. I thought of it, but dismissed it because I was afraid of side effects. But upon thinking about it, I don't see any problems. If you don't see any problems with it, why don't we try that. The only other possible bug I see is that it sends itself a :REFRESH with scheduling inhibited, which seems unnecessary, probably there is just a line of code out of place. It should have itself locked, but shouldn't inhibit scheduling. This was definitly a "misfeature", which I fixed yesterday when looking through the code, but I guess I didn't write it out since I didn't fix the other problems. I took care of it now, though.  Date: 23 DEC 1980 0155-EST From: Moon at MIT-AI (David A. Moon) Subject: That locking problem in (SHEET :EXPOSE) we discussed at dinner To: HIC at MIT-AI CC: (BUG NWS) at MIT-AI There isn't that big a locking problem. The code first checks that it can get all the locks it is going to need, then it locks them all, then it does a bunch of stuff that doesn't involve any waiting. The issue is that it has ITSELF locked through all of this procedure; actually each time it un-inhibits scheduling and goes to wait for something, it should unlock itself, and then re-lock itself before turning scheduling back off. Is there any reason the window needs to be locked around all the daemons? The only daemon I see that really cares is (ESSENTIAL-ACTIVATE :BEFORE :EXPOSE). I guess if you want to be 100% sure about him, then where it says (GO MAIN-LOOP) now it really should be a throw to a catch in the wrapper which then does the whole operation over again. Personally I would rather just flush ESSENTIAL-ACTIVATE and build it into SHEET, it is already in all but name. The only other possible bug I see is that it sends itself a :REFRESH with scheduling inhibited, which seems unnecessary, probably there is just a line of code out of place. It should have itself locked, but shouldn't inhibit scheduling.  HIC@MIT-MC (Sent by HIC at CADR1@MIT-MC) 12/21/80 18:37:19 Re: Probable bug in scroll windows To: Moon at MIT-AI CC: (BUG ZMAIL) at MIT-AI, (BUG NWS) at MIT-AI Date: 17 December 1980 04:26-EST From: David A. Moon Sender: Moon at CADR6 at MIT-AI Subject: Probable bug in scroll windows To: BUG-ZMAIL at MIT-AI, BUG-NWS at MIT-AI In the version of ZMAIL in System 53.8, ZMail 8.4, microcode 707, on LISP Machine Six: Using mark survey caused it to hang in "scroll bar" after I hit end. I had been using the scroll bar to scroll around the survey. By the way, once when I marked something far away from the current message it gratuitously put me back in the screenfull of the server that happened to have the current message on it. Control/abort would not unwedge it from this state. I tried to get it out by moving the mouse into the summary's scroll bar and back out. That wedged the mouse process. I went in with eh and unwedged everything by changing the contents of the locative the mouse process was waiting for from CLEAR to NIL. This scroll bar wedging has been fixed in the source and in a patch.  Date: 20 DEC 1980 1751-EST From: CPR at MIT-AI (Christopher P. Ryland) Sent-by: CPR at CADR10 at MIT-AI To: (BUG NWS) at MIT-AI In the version of NWS in System 51.3, ZMail 6.0, microcode 705, on LISP Machine Ten: I received a QSend whilst SUPDUPing, replied to it, used ESC ? (old keyboard) in a vain attempt to remember what END maps to on old keyboards, type a space to clear the documentation, and was thrown for a sec back to the supdup window, and then left back at the lisp listener whence I called up supdup. Odd...  Date: 20 DEC 1980 0138-EST From: Moon at MIT-AI (David A. Moon) Sent-by: Moon at CADR5 at MIT-AI Subject: Edit Screen unintuitive To: (BUG NWS) at MIT-AI I made menus able to depend on which button was clicked, and made Edit Screen follow Zmail type conventions. Clicking Left always edits the screen, clicking Right gives a menu of things to edit. I also made Set Mouse Sheet work in a similar fashion; clicking Left causes the system to move the mouse to the screen you obviously wanted. Unfortunately I couldn't find any other system menu command that could reasonably depend on which button is clicked, so it may take a while to train users to distinguish the buttons. The documentation has been updated, both OPERAT and CHOICE for the new :BUTTONS menu item flavor.  HIC@MIT-MC (Sent by HIC at CADR16@MIT-MC) 12/19/80 19:06:21 To: MMcM at MIT-AI, DLW at MIT-AI CC: (BUG NWS) at MIT-AI Date: 9 December 1980 18:05-EST From: Mike McMahon Sender: MMcM at CADR9 at MIT-AI To: DLW at MIT-AI cc: BUG-NWS at MIT-AI Date: 9 December 1980 17:43-EST From: Daniel L. Weinreb Do we want to advertise in the documentation any way to add your own items to the system menu? I think so, yes. I agree. If we do, do we then need a facilty to flush cached menus that are lying in wait somewhere? Aren't they mostly dynamic item list type menus so the right thing will happen when you change the global variable already? This is certainly the way it should be. Does anyone know why the variables with the basic alists for the system and "other" system menus are created with a DEFVAR followed by a top-level SETQ? Maybe they are trying to be defconst's, though why i don't know. Beats me...that code was certainly hacked before DEFCONST, though why they want to be DEFCONST's is beyond me...perhaps for debugging purposes...  HIC@MIT-MC (Sent by HIC at CADR16@MIT-MC) 12/19/80 18:50:32 To: JERRYB at MIT-AI, DLW at MIT-AI CC: (BUG NWS) at MIT-AI Date: 11 December 1980 11:20-EST From: Gerald R. Barber To: DLW at MIT-AI cc: BUG-NWS at MIT-AI Date: 11 December 1980 02:46-EST From: Daniel L. Weinreb Sender: dlw at CADR7 To: BUG-NWS I would like to change the definition of SHEET to make various instance variables gettable; in particular, LINE-HEIGHT, CHAR-WIDTH, SUPERIOR, and INFERIOR-LIST are important. The problem is that this will make lots of select-method lists longer, increasing working sets and making searches slower. However, I don't like having to tell people to use TV:SHEET-LINE-HEIGHT, mainly because it seems to be conceptually dirty. If we use messages, we should use messages. Does anyone have any feelings one way or the other? It seems clear that the right thing to do is to add the messages. If efficiency is an issue this early in the development of the window system maybe it is time to speed up method selection. I remember talk some time ago about putting methods in hash tables. How feasible is this, would it help or is the basic problem large working sets? I am worried that if the basic elements of the window system are expensive to use as they are now, how are users going to use them as primitive elements in the systems they develop. I agree that this schizofrenia is a bad thing, and that we should have messages for getting any of the instance variables that you'd tell someone to get. At this stage, I doubt that the speed penalty would be too severe. We should also look into the hashing scheme -- there are some good ideas floating around, and I'm sure that some of them will work without too much trouble in implementation. I think that this would make a noticable speed improvement in the window system.  Date: 18 DEC 1980 1938-EST From: BAK at MIT-AI (William A. Kornfeld) Subject: inspector To: (BUG NWS) at MIT-AI How about having the Inspector start out in the package from which the command was given to invoke it, instead of always the user package?  Date: 17 DEC 1980 0426-EST From: Moon at MIT-AI (David A. Moon) Sent-by: Moon at CADR6 at MIT-AI Subject: Probable bug in scroll windows To: (BUG ZMAIL) at MIT-AI, (BUG NWS) at MIT-AI In the version of ZMAIL in System 53.8, ZMail 8.4, microcode 707, on LISP Machine Six: Using mark survey caused it to hang in "scroll bar" after I hit end. I had been using the scroll bar to scroll around the survey. By the way, once when I marked something far away from the current message it gratuitously put me back in the screenfull of the server that happened to have the current message on it. Control/abort would not unwedge it from this state. I tried to get it out by moving the mouse into the summary's scroll bar and back out. That wedged the mouse process. I went in with eh and unwedged everything by changing the contents of the locative the mouse process was waiting for from CLEAR to NIL.  Date: 13 DEC 1980 1615-EST From: DLA at MIT-AI (David L. Andre) To: (BUG NWS) at MIT-AI CC: DLA at MIT-EECS In figuring out margins and borders, I was typing to the initial-lisp-listener things such as: (FUNCALL TV:SELECTED-WINDOW ':SET-BORDERS 5) It seems that the intuitive way to get back to no borders is to: (FUNCALL TV:SELECTED-WINDOW ':SET-BORDERS 0) but in fact, this blows up the screen, then proceeds to pretend that the border width was 1. The "right" thing to do is (FUNCALL TV:SELECTED-WINDOW ':SET-BORDERS NIL). Could 0 and NIL be parsed the same here? -- Dave  Date: 13 December 1980 16:07-EST From: Daniel L. Weinreb Sender: dlw at CADR2 at MIT-AI To: RMS at MIT-AI, BUG-NWS at MIT-AI I don't see how any "prompt window" make any difference; it DOES prompt you already, in the label of the menu. The problem is that it is hard to answer the question if you do not understand the concept that is being asked about. This is an implicit problem; you can't fix it with a fancier prompt, but only with a lecture on the nature of hierarchical windows. I am starting to belive that having separete command for editing the mouse-screen and editing a frame you are on would be a good thing. I realize that these two things are basically the same from the point of view of the NWS, but they are quite different in the minds of most users. It is purely a matter of psychology, which is important in user interface. If people are having trouble understanding this, I think that saying "well, you have to learn more about the way the NWS works" is not preferable to providing an easier-to-understand command. We pride ourselves on being able to build complex systems that are easy to use. The current problem is an example of something for which the oft-heard criticism "That's too powerful" is really true.  Date: 13 DEC 1980 0355-EST From: RMS at MIT-AI (Richard M. Stallman) To: (BUG NWS) at MIT-AI The Edit Screen operation should edit top-level windows only, and not need to ask any question about which screen's inferiors to edit. Then there should be another operation Edit Subpanes which does what Edit Screen does now. If we had a prompt window, or any other convention by which things which wait specifically for the user to select something wit the mouse could say what they want, this question would be easier to understand. I was confused by it too, not understanding what information I was supposed to give, even thoug I did understand the window hierarchy. I juust didn't know that Edit Screen wanted to operate on the inferiors of whatever I said. I just assumed it was editing the inferiors of the screen because te name "Edit Screen" seems to imply that.  Date: 12 December 1980 01:15-EST From: Mike McMahon Sender: MMcM at CADR7 at MIT-AI To: BUG-NWS at MIT-AI Date: 11 DEC 1980 2344-EST From: Henry at MIT-AI (Henry Lieberman) In System 51.17, ZMail 6.4, microcode 705, Daed vo, on LISP Machine Eight: I'm in two window mode in ZWEI. Save Layout: Layout-Name Split Screen Lisp (Edit) Existing Window (choose the lower of the two editor windows) Do It Process System Menu got an error Can't do anything but warm boot. Existing Window should obviously only offer direct inferiors of the mouse sheet. This may be difficult because of the awful way it works.  Date: 12 DEC 1980 0042-EST From: Moon at MIT-AI (David A. Moon) Sent-by: Moon at CADR3 at MIT-AI Subject: Move Window lies to you. To: DLW at MIT-AI, (BUG NWS) at MIT-AI Date: 7 DEC 1980 0252-EST From: dlw at MIT-AI (Daniel L. Weinreb) Subject: Move Window lies to you. To: (BUG NWS) at MIT-AI In system 50: Get a full size ZMACS frame, go into two window mode, enter Edit Screen on the frame, do Move Window on the top window. If you move the window to the right, it shows the left edge of the box moving away from the left edge of the frame, but if you click (meaning "do it") it does not actually put the left edge where it says; it puts the left edge at the left edge of the frame. Fixed in the source. I didn't bother making it a patch.  Date: 11 DEC 1980 1252-EST From: BAK at MIT-AI (William A. Kornfeld) Subject: Edit Screen unintuitive To: DLW at MIT-AI CC: (BUG NWS) at MIT-AI Date: 11 December 1980 02:52-EST From: Daniel L. Weinreb Sender: dlw at CADR7 at MIT-AI Unfortunately, the question being asked by that menu is intrinsically hard to understand if you are naive. We have discussed among ourselves how to make it clearer, and the present wording was chosen out of many alternatives. Do you have any suggestions for what it should say that would make the situation clearer? We don't. Well, I don't know how my usage corresponds with others, but I find when I use Edit Screen I am almost always editing "whole screen." One change that would eliminate this particular problem plus save me one level of mouse indirection most of the time would be to make Edit Screen work always on the whole screen and introduce a separate "Edit Panes" or whatever to do the other one. Edit Panes could be available from the Other option of the system menu if usage is considered low enough.  Date: 11 December 1980 11:20-EST From: Gerald R. Barber To: DLW at MIT-AI cc: BUG-NWS at MIT-AI Date: 11 December 1980 02:46-EST From: Daniel L. Weinreb Sender: dlw at CADR7 To: BUG-NWS I would like to change the definition of SHEET to make various instance variables gettable; in particular, LINE-HEIGHT, CHAR-WIDTH, SUPERIOR, and INFERIOR-LIST are important. The problem is that this will make lots of select-method lists longer, increasing working sets and making searches slower. However, I don't like having to tell people to use TV:SHEET-LINE-HEIGHT, mainly because it seems to be conceptually dirty. If we use messages, we should use messages. Does anyone have any feelings one way or the other? It seems clear that the right thing to do is to add the messages. If efficiency is an issue this early in the development of the window system maybe it is time to speed up method selection. I remember talk some time ago about putting methods in hash tables. How feasible is this, would it help or is the basic problem large working sets? I am worried that if the basic elements of the window system are expensive to use as they are now, how are users going to use them as primitive elements in the systems they develop.  Date: 11 December 1980 02:52-EST From: Daniel L. Weinreb Sender: dlw at CADR7 at MIT-AI Subject: Edit Screen unintuitive To: BAK at MIT-AI, BUG-NWS at MIT-AI Unfortunately, the question being asked by that menu is intrinsically hard to understand if you are naive. We have discussed among ourselves how to make it clearer, and the present wording was chosen out of many alternatives. Do you have any suggestions for what it should say that would make the situation clearer? We don't.  Date: 11 December 1980 02:46-EST From: Daniel L. Weinreb Sender: dlw at CADR7 at MIT-AI To: BUG-NWS at MIT-AI I would like to change the definition of SHEET to make various instance variables gettable; in particular, LINE-HEIGHT, CHAR-WIDTH, SUPERIOR, and INFERIOR-LIST are important. The problem is that this will make lots of select-method lists longer, increasing working sets and making searches slower. However, I don't like having to tell people to use TV:SHEET-LINE-HEIGHT, mainly because it seems to be conceptually dirty. If we use messages, we should use messages. Does anyone have any feelings one way or the other?  Date: 10 DEC 1980 2316-EST From: BAK at MIT-AI (William A. Kornfeld) Subject: Edit Screen unintuitive To: (BUG NWS) at MIT-AI I was helping a naive user today who wanted to reshape his editor buffer. He got EditScreen ok and then since he wanted to reshape the editor window he moused this instead of MainScreen . The reshaping took place, of course, but little did he know that he was reshaping a pane inside the window and not the window. What is disturbing about this is that there is no kind of visual feedback to let you know you are doing what you are doing.  Date: 9 DEC 1980 2155-EST From: Moon at MIT-AI (David A. Moon) Subject: Fixing up the inspector To: (BUG NWS) at MIT-AI System 51.17 has PRINT sending the :print message at the appropriate level of modularity. This should permit the unification of INSPECT and DESCRIBE. Brief documentation is in the file LMMAN;IOS >.  Date: 9 December 1980 18:05-EST From: Mike McMahon Sender: MMcM at CADR9 at MIT-AI To: DLW at MIT-AI cc: BUG-NWS at MIT-AI Date: 9 December 1980 17:43-EST From: Daniel L. Weinreb Do we want to advertise in the documentation any way to add your own items to the system menu? I think so, yes. If we do, do we then need a facilty to flush cached menus that are lying in wait somewhere? Aren't they mostly dynamic item list type menus so the right thing will happen when you change the global variable already? Does anyone know why the variables with the basic alists for the system and "other" system menus are created with a DEFVAR followed by a top-level SETQ? Maybe they are trying to be defconst's, though why i don't know.  Date: 9 December 1980 17:43-EST From: Daniel L. Weinreb Sender: dlw at CADR6 at MIT-AI To: BUG-NWS at MIT-AI In the version of NWS in System 51.13, ZMail 6.3, microcode 705, on LISP Machine Six: Do we want to advertise in the documentation any way to add your own items to the system menu? If we do, do we then need a facilty to flush cached menus that are lying in wait somewhere? Does anyone know why the variables with the basic alists for the system and "other" system menus are created with a DEFVAR followed by a top-level SETQ?  Date: 8 December 1980 16:21-EST From: Mike McMahon Sender: MMcM at CADR7 at MIT-AI Subject: squared-off, 8-cornered, 90-degree-angled To: JLK at MIT-MC cc: BUG-NWS at MIT-MC I have added (PANE-MIXIN :SQUARE-PANE-SIZE) so that you can specify that you want a square pane. For example, here are some constraints to make the upper-left corner of three panes square: (SETQ CONSTRAINTS '((MAIN . ((DUMMY PANE-3) ((DUMMY :HORIZONTAL (0.25s0) (PANE-1 PANE-2) ((PANE-1 :ASK :SQUARE-PANE-SIZE)) ((PANE-2 :EVEN)))) ((PANE-3 :EVEN))))))) I will patch this next time i happen to be writing a patch for something else.  Date: 8 December 1980 13:06-EST From: Bruce E. Edwards Sender: BEE at CADR7 at MIT-AI Subject: Supdup wants the TTY To: DLW at MIT-AI, MOON at MIT-MC cc: BUG-NWS at MIT-AI I found the hack of having local more processing and local termina-deexpose-typeout action hacking on the terminal key a great win. I stopped using it because it took so long to load my init file, because I had to place new methods on SHEET. I dont think that it is a loss to have those commands in the screen editor, but I think that at least this set should also be on the TERMINAL key. 1) OUTPUT-HOLD on output 2) Notify on output. and also 1) PROCESS-WAIT on input 2) Notify and PROCESS wait on input These take care of almost everything you want to do, and I think that it is okay to make anything else be hard.  MOON@MIT-MC 12/07/80 22:13:29 Re: Supdup wants the TTY To: dlw at MIT-AI CC: (BUG NWS) at MIT-AI, BEE at MIT-AI Date: 7 December 1980 00:02-EST From: Daniel L. Weinreb Sender: dlw at CADR2 at MIT-AI Subject: Supdup wants the TTY To: BUG-NWS at MIT-AI cc: BEE at MIT-AI A while ago I tried to reconstruct what we had decided about changing SUPDUP to notify you that it has output for you, if something comes in from the net and it is deexposed. Mike suggested that I should make it do that, but only if I add commands to change the deexposed-typeout-action. It then occured to me that it seems these commands really ought to be on the TERMINAL key and work for any kind of window, as BEE has suggested. Should we change SUPDUP? Should we add new TERMINAL commands? Bruce, what was your experience when you tried out these commands? The commands should be in the screen editor, and should allow you to change several other things besides the deexposed-typeout-action. Conceivably certain of the commands would be useful to have on the Terminal key as well. Although the NETWORK P command is supposed to be the Supdup command which deselects and sets the deexposed typeout action, it would be nice to have Lisp listeners have the same command.  Date: 7 DEC 1980 0252-EST From: dlw at MIT-AI (Daniel L. Weinreb) Subject: Move Window lies to you. To: (BUG NWS) at MIT-AI In system 50: Get a full size ZMACS frame, go into two window mode, enter Edit Screen on the frame, do Move Window on the top window. If you move the window to the right, it shows the left edge of the box moving away from the left edge of the frame, but if you click (meaning "do it") it does not actually put the left edge where it says; it puts the left edge at the left edge of the frame.  Date: 7 DEC 1980 0111-EST From: dlw at MIT-AI (Daniel L. Weinreb) To: (BUG NWS) at MIT-AI I have installed a new messge, :SET-SIZE-IN-CHARACTERS. Files SHEET and STREAM were modified.  Date: 7 December 1980 00:02-EST From: Daniel L. Weinreb Sender: dlw at CADR2 at MIT-AI Subject: Supdup wants the TTY To: BUG-NWS at MIT-AI cc: BEE at MIT-AI A while ago I tried to reconstruct what we had decided about changing SUPDUP to notify you that it has output for you, if something comes in from the net and it is deexposed. Mike suggested that I should make it do that, but only if I add commands to change the deexposed-typeout-action. It then occured to me that it seems these commands really ought to be on the TERMINAL key and work for any kind of window, as BEE has suggested. Should we change SUPDUP? Should we add new TERMINAL commands? Bruce, what was your experience when you tried out these commands?  JLK@MIT-MC 12/06/80 11:17:38 To: (BUG NWS) at MIT-MC I have a command menu which is one text line in height and it is in a constraint frame (system 50.21). When the mouse box indicates an item, the top edge of that box touches the border, making it hard to see (and it looks bad). I'm not sure if its a constraint problem or a mouse handler problem. If you want to see this, expose MC:PLOT-FRAME or generate a plot in Macsyma 4.0 (there is one on CADR15). While I'm at it, how do I specify a constraint that I want a pane to be square? I think it would be a win to have the standard command menu accept a message to turn itself off (i.e. make it no longer mouse sensitive) while it may or may not be exposed. The application I have in mind is a frame with a permanent command menu where there are times that it is inappropriate or uninterested in accepting commands from the menu. It is a nice indication to the user that the program is not listening for commands. (a further note about the square pane above, I don't think I really want that but I'm curious none the less -- what I really want is to have the pane start out square, but if the user wants to edit the frame to have it be something else, he should be able to. The problem is that if I init the Height of the pane to be equal to its width, the constraint hacker wants to change the width to fit it inside the frame borders, so they will no longer be the same. Also, what I really want is to have the inside edges be the same initially, accounting for the label -- I'm trying to get a square plotting area...)  Date: 5 DEC 1980 2027-EST From: dlw at MIT-AI (Daniel L. Weinreb) To: (BUG NWS) at MIT-AI Does anyone know if there is a message that gets you the line-height of a window?  Date: 4 DEC 1980 1759-EST From: Moon at MIT-AI (David A. Moon) To: (BUG NWS) at MIT-AI In the version of zwei in System 50.18, ZMail 5.6, microcode 701, on LISP Machine Five: Clicking Right on an unselected but exposed editor pane gives a system menu, wouldn't it be better to give an editor menu? I.e. selection doesn't work right. I.e. i.e. only Single Click Left should be different when given on an editor pane other than the selected one.  MOON@MIT-MC (Sent by MOON5@MIT-MC) 12/04/80 15:31:23 Re: Move multiple To: dlw at MIT-AI CC: (BUG NWS) at MIT-AI, ACW at MIT-AI Both of the above might be fixed by making the middle button be the "Do It" command. The right button should remain "Abort". One quick remark; in reshape and related rectangle-specifying things the middle button is Abort and the right-hand button is Do It Hairily. We should be consistent.  Date: 4 December 1980 13:54-EST From: Daniel L. Weinreb Sender: dlw at CADR9 at MIT-AI To: BUG-NWS at MIT-AI cc: ACW at MIT-AI In the version of NWS in System 50.19, ZMail 5.7, microcode 701, on LISP Machine Nine: In Move Multiple or Move Single, if there is no exposed window under the mouse (I belive that is the criterion although I am not perfectly sure), the mouse blinker (the moby arrow) becomes completely invisible, and there is no way to tell where the mouse is. You can make this happen by using Create on a Zmacs frame to create some windows in random places leaving gaps between. Also, the user interface to Move Multiple should be changed before people get used to it. There are two principle problems. First, suppose you go around to various places on the screen, turning on and off various things that you do and don't want to move multiply. Once you decide you have selected the correct set, you now want to get on with it. Unfortunately, you cannot say "get on with it" without turning on or off ONE MORE THING. The way it is now, when you make your last selection, you must know that it is going to be your last; usually, you don't. I find myself turning something off just so that the "do it" click can turn it back on again. Secondly, this is the only command we have that uses a "long click". It doesn't seem worthwhile teaching the user a whole new concept like "long click" (I am not being sarcastic) just for this one command. Either we should use long clicks in general, or not at all. I think things are complex enough as it is, and we shouldn't use long clicks. Both of the above might be fixed by making the middle button be the "Do It" command. The right button should remain "Abort". It is also a bit peculiar that when you click on an edge the first time, it turns on "both sides of the edge" (the edge and the adjacent edge), but then if you click again it only turns off the one near you. Clicking a third time turns it back on. Perhaps it would be clearer to make single-click-left always deal with both sides of the edge, and double-click-left deal with single entities. It's not that I think our users are stupid; but simple user interfaces are a good thing, even for geniuses.  Date: 2 December 1980 16:24-EST From: Daniel L. Weinreb Sender: dlw at CADR6 at MIT-AI To: BUG-NWS at MIT-AI In the version of NWS in System 50.17, ZMail 5.6, microcode 701, on LISP Machine Six: The :DRAW-CHAR message does not clip at the top of windows. Mike and I looked at the microcode for %DRAW-CHAR; Mike says it appears to be trying to correctly clip at the top of windows, but experimentation shows it does not clip at all. It does seem to clip at the bottom all right.  Date: 2 DEC 1980 0123-EST From: Moon at MIT-AI (David A. Moon) Subject: This is a zmail bug, an error-handler bug, and an nws bug To: (BUG ZMAIL) at MIT-AI, (BUG NWS) at MIT-AI In the version of ZMAIL in System 50.13, ZMail 5.5, microcode 701, on LISP Machine Nine: It died with no obvious indication of what went wrong by getting an error while the zmail frame was "with-sheet-deexposed", and the summary window was locked by the process that got the error. The error handler typed out on the typeout window of the message area, which it probably thought was exposed. (It probably was exposed, but not visible.) This happened when I was in 1-window mode and clicked left on Summarize for the first time since I had booted the machine. The bug was that a string #o 140 characters long had 141 in its fill pointer and T in its other array leader element. This was inside the scroll window update, the string was all of a summary line except the line number. I can't tell you what function it is in because I keep getting screwed by the m-Z command of the error handler. m-Z from a recursive error out of printing something flushes the state of the computation. Patching the fill pointer from 141 to 140 caused the scroll display to succeed except that that line was 1 character too long and bashed the borders of the window. Another line was also 1 character too long this way but didn't get any error (perhaps its length was 140 rather than 141?) Reminder: THE META-Z COMMAND OF THE ERROR HANDLER SUCKS DEAD BEARS!!!!!!  Date: 30 November 1980 02:07-EST From: Bruce E. Edwards Sender: BEE at CADR3 at MIT-AI Subject: Its late, and my eyes are playing tricks on me To: BUG-NWS at MIT-AI, BUG-LISPM at MIT-AI In the version of NWS in System 50.11, ZMail 5.4, microcode 701, on LISP Machine Three: Clearly my head is screwed on backwards, but in (SHEET :EXPOSE) it claims to take the arguments (&optional turn-on-blinkers bits-action ....) but later in the same code you see (funcall superior ':expose bits-action). Clearly this can't be the case, and mama, why did this ever work?  Date: 26 November 1980 21:00-EST From: Daniel L. Weinreb Sender: dlw at CADR6 at MIT-AI To: BUG-NWS at MIT-AI In the version of NWS in System 50.8, ZMail 5.4, microcode 701, on LISP Machine Six: When the system is first cold-booted, if you get a System Menu and mouse Select, the resulting menu has a "ZMACS-WINDOWS Background Stream" item in it.  Date: 25 NOV 1980 0404-EST From: Moon at MIT-AI (David A. Moon) Subject: Boxing mouse-sensitivity in system 50 To: (BUG NWS) at MIT-AI I patched the TV:HOLLOW-RECTANGULAR-BLINKER to stick out 1 pixel more on the left and the top, which makes menus look a lot better. However, I think the right thing is to redefine this blinker to stick out 2 pixels on all sides from the specified (x,y) (width,height) parameters, and take out various 1+'s and 1-'s in (basic-menu :mouse-moves) and similar places. The 2 pixels overhang are 1 for the outline and 1 for a margin inside it. This is a big change though. This system is only about 500 pages smaller than the size of the band on a T-80. It also has an enormous number of flavor compilations in it. We're going to have to do something about this; maybe I'll make flavors use temporary areas here and there to alleviate this since we seem to be unable to get compiled combined-methods in our qfasl files that don't have to be done over at load time. Also although I haven't verified this I suspect a lot of virtual memory is going to extraneous calls to FORMAT by file names. Maybe I'll work on garbage collection.  Date: 24 November 1980 00:11-EST From: Daniel L. Weinreb Sender: dlw at CADR7 at MIT-AI To: BUG-NWS at MIT-AI In the version of NWS in System 49.12, ZMail 3.6, microcode 697, on LISP Machine Seven: The :DRAW-TRIANGLE message clips to the outside borders rather than the inside borders; this causes various cruftiness in various display hacks. I think maybe there should be two versions of the drawing primitives, the second versions doing inside clipping. This would mean the microcode would have to know about the sizes of the margins.  Date: 22 NOV 1980 0236-EST From: dlw at MIT-AI (Daniel L. Weinreb) Sent-by: dlw at CADR1 at MIT-AI To: (BUG NWS) at MIT-AI In the version of NWS in System 49.12, ZMail 3.5, microcode 697, on LISP Machine One: This bug is quite reproducible, but I am not sure I can give instructions. What I do is to go into the screen editor on a zmacs pane, Move Single the (one) window's bottom to get it out of the way (move it up), create a second window in the bottom half of the pane, then create a third, smaller window on top of the second window. The second window disappears, as you would expect. Then I use "Expose (menu)". It gives me a menu of one item, the second window. I click it. Nothing happens. I can demo this for anyone who wants, if the instructions above are too vague.  Date: 20 November 1980 15:35-EST From: Daniel L. Weinreb Sender: dlw at CADR7 at MIT-AI To: BUG-NWS at MIT-AI In the version of NWS in System 49.10, ZMail 3.4, microcode 697, on LISP Machine Seven: Could the cold load stream be fixed up to support the TYI-NO-HANG operation? HOSTAT uses it, and I often call HOSTAT from the EH to determine why the net is losing, and sometimes I find myself in the cold load stream when I am in the EH.  Date: 20 NOV 1980 1440-EST From: MOON5 at MIT-MC (David A. Moon) Subject: Telnet wants the TTY. To: DLA at MIT-EECS CC: (BUG NWS) at MIT-MC There will be screen-editor commands for changing the deexposed-typeout-action (and other attributes) of a window whenever I or someone else gets around to programming it.  Date: 20 Nov 1980 1017-EST From: Dave Andre Subject: Telnet wants the TTY. To: BUG-NWS at MIT-AI cc: DLA at MIT-EECS Actually I've always found it useful to set the deexposed-typeout-action of telnets and supdups to :EXPOSE. Maybe there should be a Terminal- command for changing this? -------  Date: 19 November 1980 20:44-EST From: Daniel L. Weinreb Sender: dlw at CADR16 at MIT-AI To: BUG-NWS at MIT-AI Date: 13 NOV 1980 0200-EST From: MOON5 at MIT-AI (David A. Moon) To: (BUG NWS) at MIT-AI Perhaps supdups and telnets should be set up so that if they try to type out while deexposed they notify a "foo wants the tty" I was thinking of implementing this, but it isn't always the right thing. Right now, I am letting a BOLIO run while I do other things on the Lisp Machine, and it is a feature that it can do its typeout and I don't have to be annoyed by it. I think sometimes you want the "wants the TTY" and sometimes you don't. To make matters worse, I can think of a third useful alternative: notify me when it wants to INPUT, but not when it wants to OUTPUT. We don't have commands yet to let you specify which of these you want. I'm not sure what to do about this.  Date: 16 November 1980 21:55-EST From: Daniel L. Weinreb Sender: DLW at CADR8 at MIT-AI Subject: Click-ahead To: ED at MIT-MC, BUG-NWS at MIT-MC But a principle difference between the CAM terminal and the NWS terminal is that the CAM has a fixed (indeed, implemented in cardboard (whatever)) menu, wheras we flash up new menus (and new screen configurations with other mouse-sensitive things that may not be menus) at high speed. Very often mousing one thing creates the next thing that will be moused. If someone moused ahead, then what if a menu pops up right where he clicked, before the click is read in? That is one basic reason for omitting mouse-ahead from the user interface. Of course, since a lot of mouse-click handlers work by forcing kbd input, we do have mouse-ahead. But you don't see it often in practice; I guess I just don't do it much.  ED@MIT-MC 11/16/80 01:15:22 Re: Click-ahead To: (BUG NWS) at MIT-MC The right way to do this is what the CAM terminal does (in my humble opinion.) There is an interaction buffer, which contains in order the events from the tablet, keyboard and functionswitches. Thus the user can pick START JOB, type or pick in the job name, pick DRAW BOX and hit END to get the default box and have that all happen correctly.  Date: 13 NOV 1980 0200-EST From: MOON5 at MIT-AI (David A. Moon) To: (BUG NWS) at MIT-AI Perhaps supdups and telnets should be set up so that if they try to type out while deexposed they notify a "foo wants the tty"  Date: 12 NOV 1980 0007-EST From: dlw at MIT-AI (Daniel L. Weinreb) Subject: Input buffers To: (BUG NWS) at MIT-AI It seems from the code that if you type ahead a bunch of characters at a window, and then you mouse it and the mouse-click handler does its thing by forcing kbd input, the mouse input will appear before the keyboard input, since the keyboard input will sit in tv:kbd-io-buffer while the mouse input goes straight into the window's io-buffer. Is this true? It seems like it could have bad effects.  Date: 11 Nov 1980 2353-EST From: Dave Andre Subject: Quoting in DEFMETHOD. To: BUG-NWS at MIT-AI cc: DLA at MIT-EE If one by accident does: (defmethod (random-flavor ':random-method) ... ) accidentally quoting the method, the flavor still will accept a :random-method message. Bug or feature? Bug: If later one notices this and gratuitously removes the quote, whenever one tries to re-evaluate the defmethod, the newly defined :random-method never gets called. Shouldn't the quote cause some sort of error instead? -- Dave -------  Date: 10 November 1980 17:54-EST From: Mike McMahon Sender: MMcM at CADR7 at MIT-AI To: DLW at MIT-AI cc: BUG-NWS at MIT-AI Date: 8 NOV 1980 0131-EST From: dlw at MIT-AI (Daniel L. Weinreb) Does anybody know if it is actually possible for SHEET-HANDLE-EXCEPTIONS to find the OUTPUT-HOLD flag on? It seems like it is always called from the inside of a PREPARE-SHEET or equivalent. There is some code that calls SHEET-HANDLE-EXCEPTIONS not from within a PREPARE-SHEET, partially with the object of checking OUTPUT-HOLD.  Date: 10 November 1980 17:44-EST From: Mike McMahon Sender: MMcM at CADR7 at MIT-AI To: DLW at MIT-AI cc: BUG-NWS at MIT-AI Date: 8 NOV 1980 0133-EST From: dlw at MIT-AI (Daniel L. Weinreb) When you TYO a special character and PRINT-LOSENGED-STRING is called, it checks for the END-OF-LINE exception before calling SHEET-HANDLE-EXCEPTIONS. This means that it handles exceptions in a different order than all other kinds of TYOing, which might make a difference sometimes. Is there a good reason for this or can it be fixed? I do not see a case where it can make a difference, since END-OF-LINE-EXCEPTION cannot clear any exceptions. However, it can set exceptions so it is important that SHEET-HANDLE-EXCEPTIONS get called after it is run. You presumably realise that SHEET-HANDLE-EXCEPTIONS is never responsible for sending a :END-OF-LINE-EXCEPTION message.  Date: 10 November 1980 13:10-EST From: Howard I. Cannon Subject: :clear-screen To: dlw at MIT-AI cc: BUG-NWS at MIT-AI I believe that I mentioned this point before as wel. Remove the argument.  Date: 10 November 1980 03:27-EST From: Daniel L. Weinreb Sender: dlw at CADR8 at MIT-AI To: BUG-NWS at MIT-AI In the version of NWS in System 48.19, ZMail 1.2, microcode 696, on LISP Machine Eight: The documentation on the :clear-screen message tells you that it takes the margins-too argument, and then tells you that you should never ever give the argument. This is rather unfortunate and looks kind of stupid. Is that argument actually necessary; that is, does anyone actually clear the margins by message-sending rather than by calling tv:sheet-clear? It would be nice if we could remove the argument, if you really aren't suposed to pass it!  Date: 10 November 1980 00:22-EST From: Daniel L. Weinreb Sender: dlw at CADR8 at MIT-AI To: BUG-NWS at MIT-AI In the version of NWS in System 48.19, ZMail 1.2, microcode 696, on LISP Machine Eight: When you are reading your mail with ZMail, it can be hard to get a scroll bar in the message window. The problem is that you have to move to the left without getting any feedback for a long time; then you are in the scroll bar but by the time you have noticed that you are out of it again by having gone off the left end of the scroll region. Now you have to move right and then a long way left again to get back in. This can get kind of painful. The stickiness of the mouse balls has something to do with it.  Date: 8 NOV 1980 0148-EST From: BAK at MIT-AI (William A. Kornfeld) Subject: Layouts and the SYSTEM key To: (BUG NWS) at MIT-AI It would be nice if you could get to a saved layout without going through menus. When defining a layout the user could have the option of hanging it off a character not already used with the SYSTEM key. Then when typing SYSTEM-char the saved layout would be picked. Since selecting a saved layout is conceptually similar to selecting a window this would present a consistent (extensible) interface to the user.  Date: 8 NOV 1980 0133-EST From: dlw at MIT-AI (Daniel L. Weinreb) To: (BUG NWS) at MIT-AI When you TYO a special character and PRINT-LOSENGED-STRING is called, it checks for the END-OF-LINE exception before calling SHEET-HANDLE-EXCEPTIONS. This means that it handles exceptions in a different order than all other kinds of TYOing, which might make a difference sometimes. Is there a good reason for this or can it be fixed?  Date: 8 NOV 1980 0131-EST From: dlw at MIT-AI (Daniel L. Weinreb) To: (BUG NWS) at MIT-AI Does anybody know if it is actually possible for SHEET-HANDLE-EXCEPTIONS to find the OUTPUT-HOLD flag on? It seems like it is always called from the inside of a PREPARE-SHEET or equivalent.  Date: 7 November 1980 17:06-EST From: Daniel L. Weinreb Sender: dlw at CADR7 at MIT-AI Subject: Re: Telnet bombs out. To: BUG-NWS at MIT-AI cc: DLA at MIT-EECS Date: 6 Nov 1980 1603-EST From: Dave Andre Actually, what I think was happening was that so much crunching was going on, that two clicks never got through to the mouse process in a close enough proximity. -- Dave ------- Gee, it looks like encoding of clicks does not happen with interrupts inhibited; there is a comment saying that "in this future" this should be done. As it says in Bozos, welcome to the future! Should this change be made?  Date: 7 NOV 1980 0335-EST From: DLW at MIT-AI (Daniel L. Weinreb) Sent-by: DLW5 at MIT-AI To: (BUG NWS) at MIT-AI The file LMWIN;SCRMAN 147, which is the latest version, got a non-recoverable disk error. I have restored the file from backup tape.  Date: 6 November 1980 01:08-EST From: Howard I. Cannon Subject: [JLK at MIT-MC: Forwarded] To: dlw at MIT-AI cc: BUG-NWS at MIT-AI, JERRYB at MIT-AI Alright, I concede....Abort is a regular key, Control-Abort is what Abort is now....  Date: 5 November 1980 01:31-EST From: Daniel L. Weinreb Sender: dlw at CADR15 at MIT-AI Subject: [JLK at MIT-MC: Forwarded] To: HIC at MIT-MC cc: JERRYB at MIT-AI, BUG-NWS at MIT-AI I agree that Abort is very useful the way it is now. Unfortunately, there is a shortage of keys, even on the new keyboards. It would be nice to put everything on a single, unshifted key. Unfortunately, there is a scarcity of resources, and Abort can only mean one of the two things. I think we should have End and Abort keys just as we have Do It and Abort menu items (or Done and Exit menu items). It is a natural pairing of functionality. Having them be End and Control-Abort is just a bit less crufty than the present set of End and Control-]. Much as the present Abort function is useful, I would prefer to have Abort be used as the complement of End, and move the present function to Control-Abort.  Date: 5 November 1980 01:27-EST From: Daniel L. Weinreb Sender: dlw at CADR15 at MIT-AI To: HIC at MIT-MC cc: JERRYB at MIT-AI, BUG-NWS at MIT-AI While I can sympathize with the way (inspect ...) works now, it really is counterintuitive that it does not create a process. It indeed has the same problem as Daedalus does. So I think I agree that (inspect ...) should create a new process.  Date: 5 November 1980 01:25-EST From: Daniel L. Weinreb Sender: dlw at CADR15 at MIT-AI Subject: Daedalus tying up a Lisp window To: MOON at MIT-AI cc: BUG-NWS at MIT-AI I don't understand what difference it would make if Daedalus were to use TV:WINDOW-CALL. It seems to behave that way the way it is. Maybe I don't understand what TV:WINDOW-CALL does?  Date: 4 November 1980 20:09-EST From: Howard I. Cannon Subject: [JLK at MIT-MC: Forwarded] To: JERRYB at MIT-AI cc: BUG-NWS at MIT-AI, MMCM at MIT-AI You can't use abort with a prefix and have it means what it does now, since that requires too much programmatic interaction, and when your machine is running wild...you could use abort either controllified or metaed. I am against changing it's current meaning, though, since I find it very useful the way it is now.  Date: 4 November 1980 20:07-EST From: Howard I. Cannon To: JERRYB at MIT-AI cc: BUG-NWS at MIT-AI, DLW at MIT-AI, MMCM at MIT-AI Date: 3 November 1980 23:03-EST From: Gerald R. Barber To: MMCM at MIT-AI cc: BUG-NWS at MIT-AI, DLW at MIT-AI Date: 3 November 1980 12:54-EST From: Mike McMahon To: DLW cc: BUG-NWS If I am in Daedalus and I want to do some Lisping, I type System-L and it gets me back to the Lisp Listener window associated with the same process at which I typed "(do-it)" and which is therefore busy running Daedalus. Daedalus has no excuse for not having its own process. It would be nice if (inspect thing) would cause the inspector to run in its own process also. That can be made to work if you want, what do people think?  Date: 4 NOV 1980 1702-EST From: Moon at MIT-AI (David A. Moon) Subject: Daedalus tying up a Lisp window To: DLW at MIT-AI CC: (BUG NWS) at MIT-AI The macro TV:WINDOW-CALL is supposed to be what programs are supposed to use to avoid this; too bad it isn't documented. Daedalus probably wants to use a separate process anyway, but things that don't should use window-call.  Date: 4 November 1980 00:48-EST From: Daniel L. Weinreb Sender: dlw at CADR6 at MIT-AI Subject: ABORTions To: BUG-NWS at MIT-AI, JLK at MIT-MC I am strongly in favor of making ABORT be a normal key, so that it can replace c-], and moving the present functionality to Control-ABORT or Terminal-ABORT or something. I haven't had a chance to discuss this with everyone else yet. Of course there's no reason c-] can't still work, but the prompt need not mention it.  Date: 4 November 1980 00:45-EST From: Daniel L. Weinreb Sender: dlw at CADR6 at MIT-AI To: BUG-DAEDALUS at MIT-AI cc: BUG-NWS at MIT-AI The (do-it) function really ought to be like the (ed) function and create a new process for Daedalus to run in. The way things are now, it uses the Lisp Listener process and so you cannot use that window to do some lisping while you are running daedalus.  Date: 3 November 1980 23:03-EST From: Gerald R. Barber To: MMCM at MIT-AI cc: BUG-NWS at MIT-AI, DLW at MIT-AI Date: 3 November 1980 12:54-EST From: Mike McMahon To: DLW cc: BUG-NWS If I am in Daedalus and I want to do some Lisping, I type System-L and it gets me back to the Lisp Listener window associated with the same process at which I typed "(do-it)" and which is therefore busy running Daedalus. Daedalus has no excuse for not having its own process. It would be nice if (inspect thing) would cause the inspector to run in its own process also.  Date: 3 November 1980 22:54-EST From: Gerald R. Barber Subject: [JLK at MIT-MC: Forwarded] To: HIC at MIT-MC cc: BUG-NWS at MIT-AI, MMCM at MIT-AI Date: 3 November 1980 15:02-EST From: Howard I. Cannon To: MMcM cc: BUG-NWS Re: [JLK at MIT-MC: Forwarded] Yes, I'd like to find some key to use other than control-]. Unfortunatly, I don't have any good suggestions. Can't we find another key on that silly keyboard that would make sense? What is wrong with letting either [system] or [terminal] abort do what abort does now and letting programs interpret abort as they see fit?  Date: 3 NOV 1980 2236-EST From: Moon at MIT-AI (David A. Moon) To: (BUG NWS) at MIT-AI A disk error while paging a bit array in or out tends to leave the window system's data bases completely clobbered, if one uses term c-clear in order to be able to see the error message. The bugs here are two: 1. The error handler isn't nearly smart enough about when to use the cold-load stream. It should be sufficiently smart that any error inside an expose or deexpose (i.e. any error when the current-process has any windows locked) causes it to use the cold-load stream. Otherwise you can't see the error message without unlocking locks, which if done at that time leaves things inconsistent. 2. The window system and/or the user paging code should handle disk errors on bit arrays gracefully; e.g. let the regular paging mechanism handle it (it tends to work better because it doesn't use multi-block transfers which are more liable to overruns).  Date: 3 November 1980 15:02-EST From: Howard I. Cannon Subject: [JLK at MIT-MC: Forwarded] To: MMcM at MIT-AI cc: BUG-NWS at MIT-AI Yes, I'd like to find some key to use other than control-]. Unfortunatly, I don't have any good suggestions. Can't we find another key on that silly keyboard that would make sense?  Date: 3 November 1980 13:15-EST From: Mike McMahon Sender: MMcM at CADR6 at MIT-AI Subject: [JLK at MIT-MC: Forwarded] To: BUG-NWS at MIT-AI JLK@MIT-MC 11/01/80 10:59:29 If find this CONTROL-] for aborting very distasteful. I think the arguement about compatibility with EMACS on the 10 is vacuous because Emacs on the 10 doesn't have END either. Is there some reason that ABORT would not be the right thing? Or Control-ABORT or something using the ABORT key?  Date: 3 November 1980 12:54-EST From: Mike McMahon To: DLW at MIT-AI cc: BUG-NWS at MIT-AI Date: 2 November 1980 01:02-EST From: Daniel L. Weinreb If I am in the editor and it bombs out and I enter the window error handler and then decide I want to edit something as part of fixing the bug, I type System-E to get an editor, and it gets me the one that has blown out. (In fact, I can't even create a new one since there is only one ZMACS process, but that is another problem.) There should be an option, either meta bit or numeric argument, that forces the creation of a new window of the specified type. If I am in Daedalus and I want to do some Lisping, I type System-L and it gets me back to the Lisp Listener window associated with the same process at which I typed "(do-it)" and which is therefore busy running Daedalus. Daedalus has no excuse for not having its own process.  Date: 3 November 1980 01:59-EST From: Daniel L. Weinreb Sender: dlw at CADR6 at MIT-AI Subject: Top level binding of TERMINAL-IO To: HIC at MIT-MC cc: BUG-NWS at MIT-AI, BUG-LMMAN at MIT-AI Oh. Stupid of me. That's too bad; I don't see a reasonable fix for the problem either. I guess we'll just have to document it. Very disappointing.  Moon@MIT-MC (Sent by Moon at CADR6@MIT-MC) 11/02/80 22:49:57 To: BAK at MIT-AI CC: (BUG NWS) at MIT-AI Date: 2 NOV 1980 1743-EST From: BAK at MIT-AI (William A. Kornfeld) To: (BUG NWS) at MIT-AI When a flavor is defined with the :gettable-instance-variables option, the respective access messages are defined in the user package rather than the package of the instance variable. There are some applications for which this is inappropriate. If the instance variables are decided by a program (thus names are known at runtime only) it is very convenient for the instance variables and message names to be EQ. Since there are probably some arguments for the current scheme, I would suggest both be available as options. It is not possible to have message names in other than the keyword package without impracticably large modifications to the system.  Date: 2 November 1980 18:08-EST From: Howard I. Cannon Subject: NWS gripe/question To: DEKLEER at PARC-MAXC2 cc: BUG-nws at MIT-AI Sigh, there is no provision to do what yo want to do with regards to dynamic item lists. I suggest that you make the menu big enough to hold what you want to hold, by explictly specifying a number of lines. The :EVEN constraint uses up the rest of the area, and should be used as the last constraint. Note that there may be many :EVEN's, but they must appear in a "constraint group" by themselves and it must be the last constraint group.  Date: 2 November 1980 18:01-EST From: Howard I. Cannon Subject: Top level binding of TERMINAL-IOTo: Daniel L. Weinreb cc: BUG-NWS at MIT-AI I think you're a bit confused..."the top level value of terminal-io in a lisp listener should be"...umm, how can the top-level value be different for Lisp Listeners than for aything else? That's the whole point, isn't it? I thinnk that it would reduce functonality to change it to be something else (though for the life of me I couldn't figure out what the right thing would be). I ally don't see any way arund this problem. It should just be well documented somewhere.  Date: 2 NOV 1980 1743-EST From: BAK at MIT-AI (William A. Kornfeld) To: (BUG NWS) at MIT-AI When a flavor is defined with the :gettable-instance-variables option, the respective access messages are defined in the user package rather than the package of the instance variable. There are some applications for which this is inappropriate. If the instance variables are decided by a program (thus names are known at runtime only) it is very convenient for the instance variables and message names to be EQ. Since there are probably some arguments for the current scheme, I would suggest both be available as options.  Date: 2 November 1980 02:14-EST From: Daniel L. Weinreb Sender: dlw at CADR6 at MIT-AI To: BUG-NWS at MIT-AI In the version of NWS in System 48.3, microcode 696, on LISP Machine Six: If a naive user tries to play arounhd with stack groups, the following weird phenomenon can be pretty hard to figure out: switching stack groups undoes the binding of terminal-io, which causes the value of terminal-io to be a backgroup-lisp-interactor for the current Lisp Listener (from which the user is hacking around). So when he prints things out, they don't appear, although he does get a message saying "[Process Initial Process wants the TTY]", which is very weird since it already HAS the TTY; I mean, you are typing at it, aren't you? This faked me out badly just now. Maybe the top level value of terminal-io in a Lisp Listener should be the window itself, instead of having this be a binding.  Date: 2 November 1980 01:02-EST From: Daniel L. Weinreb Sender: dlw at CADR6 at MIT-AI To: BUG-NWS at MIT-AI cc: BUG-ZWEI at MIT-AI In the version of NWS in System 48.3, microcode 696, on LISP Machine Six: The way the System key works leaves something to be desired. Two examples: If I am in the editor and it bombs out and I enter the window error handler and then decide I want to edit something as part of fixing the bug, I type System-E to get an editor, and it gets me the one that has blown out. (In fact, I can't even create a new one since there is only one ZMACS process, but that is another problem.) If I am in Daedalus and I want to do some Lisping, I type System-L and it gets me back to the Lisp Listener window associated with the same process at which I typed "(do-it)" and which is therefore busy running Daedalus. This is a confusion between processes and windows. I am not sure what to do about it, but I suspect maybe System really wants to select processes, or something.  Date: 2 November 1980 00:28-EST From: Daniel L. Weinreb Sender: dlw at CADR6 at MIT-AI To: BUG-ZWEI at MIT-AI, BUG-NWS at MIT-AI In the version of ZWEI in System 48.3, microcode 696, on LISP Machine Six: In Dired, when it puts up the list of files that it is about to delete, I happened to notice that the filenames are mouse-sensitive. Wondering what it would mean to mouse one, I tried it; the right button gets a system menu and the others feep. Are these really not supposed to be mouse-sensitive, or is there a problem with :mouse-click?  Date: 1 NOV 1980 1118-PST From: DEKLEER at PARC-MAXC2 Subject: NWS gripe/question To: bug-nws at MIT-AI I defined a dynamic menu pane as: (defflavor dynamic-menu-pane () (tv:command-menu-pane tv:dynamic-item-list-mixin)) (defvar *interaction-window* (tv:window-create 'aedes-frame ':save-bits t ':panes `((menu dynamic-menu-pane :item-list-pointer *aedes-commands*) (interaction-pane pane :label nil :more-p nil)) ':constraints '((main . ((menu interaction-pane) ((menu :ask :pane-size) (interaction-pane 25 :lines))))) ':selected-pane 'interaction-pane)) It works fine, except when the list of commands overflows a line --- the menu pane does not automatically grow. You have to explicitly call :set-edges again on the frame which expands menu and moves interaction-pane down (the frame has some space left over on the bottom.) Is there someway to do this automatically, do it on a :refresh, or signal the program in some way. This brings up a second question. What constraint do I specify to get the remainder of the frame. It seems from looking at the source that something like :limit (1 nil :lines) but that gets the error that nil is not a valid constraint. Maybe my world here is broken in this regard. -------  Date: 31 October 1980 13:33-EST From: Mike McMahon Sender: MMcM at CADR6 at MIT-AI To: BUG-ZWEI at MIT-AI, BUG-LISPM at MIT-AI, BUG-NWS at MIT-AI A number of source files are missing from the NZWEI; directory. They were present last night when they were compiled and a new system made from them and gone by this morning when the dump was taken. I do not know yet whether the culprit was programmatic or not. Other directories may have been affected as well. Please DO NOT TOUCH ANYTHING until i have completely analysed the damage. One skew has already occurred: Moon fixed SAVE-ALL-FILES since it appeared broken in the source, although the previously fixed version from last night made it into this new load.  Date: 30 October 1980 23:28-EST From: Howard I. Cannon Subject: Stream operations to a frame passing on to selected pane To: MOON at MIT-MC cc: BUG-nws at MIT-AI, johan at MIT-AI Date: 10/30/80 16:28:03 From: MOON at MIT-MC To: johan at MIT-AI cc: (BUG nws) at MIT-AI Re: Stream operations to a frame passing on to selected pane Actually, if you need this it is almost certainly a sign that your program is organized incorrectly. Barf. This one you'll have to back up. It is not at all clear to me that I agree with this.  MOON@MIT-MC 10/30/80 16:28:03 Re: Stream operations to a frame passing on to selected pane To: johan at MIT-AI CC: (BUG nws) at MIT-AI Actually, if you need this it is almost certainly a sign that your program is organized incorrectly.  Date: 28 October 1980 20:27-EST From: Mike McMahon Sender: MMcM at CADR6 at MIT-AI To: DLW at MIT-AI cc: BUG-NWS at MIT-AI Date: 28 October 1980 20:22-EST From: Daniel L. Weinreb Today I again ran into the problem of RECORD-DEFUN not working when you are editing a message inside ZMAIL. The bug I want to report is that while trying to type out the error message, it went blocked trying to expose the sheet on which it intended to print the error. There was a three line window at the bottom of the screen at the time RECORD-DEFUN was called, on which it had printed out "Evaluating Region". So I could not see the error. The problem here is that the error handler does not insure that the window you are interacting with is visible. It should also count as the "user initiatiated" type of selection that forces temporary windows out of the way.  Moon@MIT-MC (Sent by Moon at CADR9@MIT-MC) 10/28/80 01:50:54 To: (BUG NWS) at MIT-AI 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.  Date: 28 OCT 1980 0033-EST From: MOON at MIT-AI (David A. Moon) Subject: Important things still to be done to the window system To: (BUG NWS) at MIT-AI I put (or will have in an hour or so) in the file AI:LMWIN;TASK LIST a list of all the problems with the window system that I could think of that were "design issues" rather than "bugs", including things from my old mail. Please read and annotate, or even (Heaven forbid!) come up with solutions!  MOON@MIT-MC 10/27/80 23:10:10 Re: Screen management and windows without bit arrays To: (BUG NWS) at MIT-AI I checked over Howard's change and got rid of the SCREEN-MANAGE-PARTIALLY-VISIBLE-MIXIN I had put in and PANE-MIXIN's unnecessary :SCREEN-MANAGE-RESTORE-AREA method. So as of the next system it should always work to redefine :SCREEN-MANAGE-DEEXPOSED-VISIBILITY to return T.  Date: 26 OCT 1980 1451-EST From: HIC at MIT-AI (Howard I. Cannon) Subject: Screen management and windows without bit arrays To: (BUG NWS) at MIT-AI I made a change to SCRMAN that should obviate the need for the new screen manager mixin. Just redefining :screen-manage-deexposed-visibility should now do the right thing. Please take a look at it.  Date: 26 OCT 1980 1427-EST From: DLW at MIT-AI (Daniel L. Weinreb) Subject: Modularity of :MOUSE-BUTTONS To: HIC at MIT-MC CC: (BUG NWS) at MIT-AI I also agree with Moon's proposal; I think this does everything all of us want. The new message should be combined with :OR combination to make it easy to handle only some buttons.  Date: 25 October 1980 16:24-EDT From: Howard I. Cannon Subject: Small system change To: Moon at MIT-AI cc: BUG-NWS at MIT-AI, DLW at MIT-AI Date: 20 October 1980 21:50-EDT From: David A. Moon To: BUG-NWS at MIT-AI cc: DLW at MIT-AI Re: Small system change I added SCREEN-MANAGE-PARTIALLY-VISIBLE-MIXIN, which makes a window be visible when it is partially exposed even if it has no bit save array. (The default is to have such windows fully disappear). Possibly we want to change the default and make a mixin that does what the default is now. This would be alright, as long as the default is to have :SCREEN-MANAGE-DEEXPOSED-VISIBILITY return (NOT (NULL BIT-ARRAY)) [it better have a mixin on :set-save-bits too!]. Perhaps we should add a new instance variable. But I don't think that the default should be to have these non-saved windows be visible, since that involves a lot of hidden computation, and sometimes some bizarre results. If the window disappears altogether, then you know what's going on. If only the insides disappear (like with the case of a lisp listener put into this mode), then you might just get convinced that we're all a bunch of loonies (the reason is probably far from obvious)...why am I rambling... --Howard  Date: 25 October 1980 16:17-EDT From: Howard I. Cannon Subject: :MOUSE-BUTTONS/:MOUSE-CLICK To: MOON5 at MIT-AI cc: BUG-NWS at MIT-AI Date: 25 October 1980 04:54-EDT From: David A. Moon To: BUG-NWS at MIT-AI Re: :MOUSE-BUTTONS/:MOUSE-CLICK I don't think a new mixin is necessary; if the default :MOUSE-BUTTONS method does encoding and sends the :MOUSE-CLICK message, and the default :MOUSE-CLICK method calls the system menu on single-click-right and otherwise does nothing, the current behavior will exist except that the system menu will be slightly slower to get since encoding will happen by default (I doubt anyone will notice), a user who redefines :MOUSE-BUTTONS will get the same behavior as now, and a user who redefines :MOUSE-CLICK instead of :MOUSE-BUTTONS will get the desired new behavior. I agree with this.  Date: 25 OCT 1980 0454-EDT From: MOON5 at MIT-AI (David A. Moon) Subject: :MOUSE-BUTTONS/:MOUSE-CLICK To: (BUG NWS) at MIT-AI I don't think a new mixin is necessary; if the default :MOUSE-BUTTONS method does encoding and sends the :MOUSE-CLICK message, and the default :MOUSE-CLICK method calls the system menu on single-click-right and otherwise does nothing, the current behavior will exist except that the system menu will be slightly slower to get since encoding will happen by default (I doubt anyone will notice), a user who redefines :MOUSE-BUTTONS will get the same behavior as now, and a user who redefines :MOUSE-CLICK instead of :MOUSE-BUTTONS will get the desired new behavior.  Date: 25 OCT 1980 0448-EDT From: MOON5 at MIT-AI (David A. Moon) Subject: Changing :MOUSE-BUTTONS To: (BUG NWS) at MIT-AI It actually sounds reasonable to me that :MOUSE-BUTTONS should receive the raw buttons and :MOUSE-CLICK should receive it decoded into clicks and with double-click-right already filtered out and so forth  Date: 25 October 1980 01:18-EDT From: Howard I. Cannon Subject: Modularity of :MOUSE-BUTTONS To: dlw at MIT-AI cc: BUG-NWS at MIT-AI OK, minor communication problem here. Well, the thing I am afraid of is changing this thing now, since there is a fair amount of code out there, not all of it easilly findable, that uses mouse-buttons. I agree in principle with keeping the short names associated with simple behaviour, but in this case I think making this change would be detrimental. People keep complaining that the system changes out from underneath them, and this would be a prime example where it doesn't buy yu a whole hell of a lot. I'd appreciate it if you'd put a little thought into doing this thing without impacting all the users. LIke perhaps mouse-buttons and could be made to have the new behaviour (I am not sggesting that the 'simple' message should be :mose-buttons-cooked, btw. I think perhaps :mouse-click or :mouse-input or even :buttons. Some suitable short, reasonable name is probably within reach). I doubt that it would break anything -- the people who redefine :mose-buttons would redefine it, and those who don't probably don't care anyway. The main thing I'm leary about is changing the name of mouse-buttons, then MAKING MOUSE-BUTTONS MEAN SOMETING DIFFERENT.  Date: 24 October 1980 21:31-EDT From: Daniel L. Weinreb Sender: dlw at CADR7 at MIT-AI Subject: Modularity of :MOUSE-BUTTONS To: HIC at MIT-MC cc: BUG-NWS at MIT-AI Oh, I see. I thought you objected to the whole concept, rather than just the names. Sorry about that. The reason I want to change the names is because if we leave them the way they are, the documentation must read "to get the simple behavior, you must add this here mixin and handle this message with a long name", rather than "to get the simple behavior, handle this message with a short name". That is, I think the short names should be assigned to the simple behavior, and long names to the complex behavior, where "complex" is from the point of view of the USERs rather than us. Sure, the raw thing is more general and primitive, but from the point of view of the user, it requires more work to make the right things happen; if you aren't careful, it won't update the activity time, nor will you be able to get to the system menu. I'd like it to be as simple and painless as possible to write programs that use the mouse, and I think reducing the number of mixins you need (in the spirit of making TV:WINDOW mix in most of the most useful things) and keeping the simple message names short will help make the NWS more usable and friendly.  Date: 24 October 1980 12:12-EDT From: Howard I. Cannon Subject: Modularity of :MOUSE-BUTTONS To: dlw at MIT-AI cc: BUG-NWS at MIT-AI Date: 23 October 1980 20:47-EDT From: Daniel L. Weinreb Sender: dlw at CADR6 at MIT-AI To: HIC cc: BUG-NWS at MIT-AI Re: Modularity of :MOUSE-BUTTONS If you had read my previous messages you would have had all your questions answered in detail. Bullshit. I still do not understand what difference it makes whether you call your message :MOUSE-BUTTONS or :MOSE-BUTTONS-COOKED. The documentaton would rad like this: "If you want simple mous button handling, mixin the COOKED-BUTTONS-MIXIN flavor and then define the method :MOE-BUTTONS-COOKED. The COOKED-BUTTONS-MIXIN has a handler for :MOusE-BUTTONS that does the right thing, and then, if necessary, sends a message to :MOUSE-BUTTONS-COOKED" Now, insted of insulting me, kindly answer the question.  Date: 24 October 1980 12:09-EDT From: Howard I. Cannon Subject: More answer about mouse-buttons To: DLW at MIT-AI cc: BUG-NWS at MIT-AI The word "losing" gets used around here interchangably with "gratuitous". You are suggesting renaming a message, whereas my suggestion merely added a new message. Since you can get equivalent functionality from either scheme (in fact, idntical functonality), I consider changing the name of a currently existing message to be gratuitous (i.e. it buys you nothing). I don't know whether it's losing or not, maybe it's the right thing. I tend not to think so. a mixin that imp,  Date: 23 OCT 1980 2054-EDT From: DLW at MIT-AI (Daniel L. Weinreb) Subject: More answer about mouse-buttons To: HIC at MIT-AI CC: (BUG NWS) at MIT-AI OK, here is what I said originally: This is the same as the KBD-MOUSE-BUTTON-MIXIN one (if I have the name correctly), except that instead of forcing in a fixnum with the %%KBD-MOUSE bit on, it sends a blip so that it can send the X and Y positions also. It is unfortunate that I have to copy all the rest of the code besides the last line. I suggest that we replace the existing message with a :MOUSE-BUTTONS-RAW message, and replace the last line of its handler with a FUNCALL-SELF MOUSE-BUTTONS. Then a random user can install a simple handler, and things like the activity time and the calling of the system menu and the selection process will all happen automatically, without everyone having to copy the code all the time. If nobody objects, I will do this. That is why. The change is not gratuitous; the word "gratuitous" gets used around here interchangably with "losing".  Date: 23 October 1980 20:47-EDT From: Daniel L. Weinreb Sender: dlw at CADR6 at MIT-AI Subject: Modularity of :MOUSE-BUTTONS To: HIC at MIT-MC cc: BUG-NWS at MIT-AI If you had read my previous messages you would have had all your questions answered in detail.  Date: 23 October 1980 19:00-EDT From: Howard I. Cannon Subject: Modularity of :MOUSE-BUTTONS To: dlw at MIT-AI cc: BUG-NWS at MIT-MC, MOON at MIT-MC It doesn't sound good to me. Why can't you make a mixin? I don't understand why you have to modify all existing code. The functionality that currently exists is more than enough to allow you to implement what you want. Therefore, I see no reason to make gratuitous changes to it.  Date: 23 October 1980 16:12-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 46.1, with microcode 692, on LISP Machine Eight: There is a real problem in the way scroll bars work now. The problem is that the non-simple geometry is an excellent mimic of the mouse's principle failure mode. When you try to get into a scroll bar, you don't get any feedback telling you that you are on your way, and, as a result, you (well, I do, at least) assume that the mouse is slipping, and you start banging it against the table and getting frustrated. The non-simple geometry is a good idea, but it just does not make it in the current system. It is mostly on the way out that this happens. Moon just came in and suggested that once you are in the scroll bar, it should do proper left-to-right following of the mouse. This sounds good to me.  Date: 23 October 1980 14:22-EDT From: Daniel L. Weinreb Sender: dlw at CADR17 at MIT-AI Subject: Modularity of :MOUSE-BUTTONS To: MOON at MIT-MC cc: BUG-NWS at MIT-MC When I said I would "replace the existing message", I thought everyone would understand that I meant replacing the message, not just replacing the handler. Of course, I intended to modify every existing handler to use the name :MOUSE-BUTTONS-RAW, and this would not break any code. Next time I'll try harder to spell out in detail exactly what I mean. Moon is right, though, you might want to handle certain buttons and not others, but having it send a different message for each button would lose. Sounds to me like a great application for :OR combination, so that any flavor could handle the ones it wants and punt the rest of them to the next handler. How does that sound?  Date: 23 October 1980 12:17-EDT From: Howard I. Cannon To: dlw at MIT-AI cc: BUG-NWS at MIT-AI The negative screen manager priority to fix the showing through problem sounds like the right thing. Then, EXPOSE, or SELECT (depending on your taste), could set the priority back to normal. I like that idea.  Date: 23 October 1980 12:16-EDT From: Howard I. Cannon Subject: Modularity of :MOUSE-BUTTONS To: dlw at MIT-AI cc: BUG-NWS at MIT-AI I agree with MOON's objections -- you can't just go off and change this, since it will probably break most programs. I suggest that you implement a mixin that does what you want, except insted of calling it mouse-buttons-raw and mouse-buttons, call the messages mouse-buttons and mouse-buttons-cooked. That way, you leave the current functionality, and get the new functionality, without breaking any code.  MOON@MIT-MC 10/23/80 02:00:03 Re: Modularity of :MOUSE-BUTTONS To: dlw at MIT-AI CC: (BUG NWS) at MIT-MC Your proposed change would break every program that uses the mouse, because the guy responsible for encoidng the double clicks would change. Let's think about this more before going off half-cocked. One thing is that you also want to make it easy to change the handling of single buttons individually, except that doing that by making it send a different message for each button would mean a lot of duplicated code in some programs.  Date: 23 October 1980 01:20-EDT From: Daniel L. Weinreb Sender: dlw at CADR6 at MIT-AI To: BAK at MIT-AI cc: BUG-NWS at MIT-AI BAK@MIT-AI 10/23/80 01:01:13 How about having a window called "The backdrop" which is either all white or black and starts out on top of not-yet-invoked windows? That's an interesting idea, but I think it has some problems. Sooner or later the user will find this thing; he will find himself reshaping it or something and not understand what it is. This would be better than the present situation, but it doesn't sound like the Right Thing.  Date: 23 OCT 1980 0101-EDT From: dlw at MIT-AI (Daniel L. Weinreb) Subject: Modularity of :MOUSE-BUTTONS To: (BUG NWS) at MIT-AI I recently wanted changed BASIC-TELNET to handle mouse clicks, by sending the mouse buttons along with the X and Y coordinates to the TELNET process. Now, I have since been told that there is an installed mixin for this. However, make belive there isn't, just for the time being. Here is the code I wrote. (DEFMETHOD (BASIC-TELNET :MOUSE-BUTTONS) (BD X Y) (SETQ TV:KBD-LAST-ACTIVITY-TIME (TIME)) (LET ((BUTTONS (TV:MOUSE-BUTTON-ENCODE BD))) (COND ((= BUTTONS #\MOUSE-3-2) (TV:MOUSE-CALL-SYSTEM-MENU)) ((NEQ SELF TV:SELECTED-WINDOW) (PROCESS-RUN-FUNCTION "Mouse Select" SELF ':SELECT)) (T (FUNCALL-SELF ':FORCE-KBD-INPUT (LIST ':MOUSE X Y BUTTONS)))))) This is the same as the KBD-MOUSE-BUTTON-MIXIN one (if I have the name correctly), except that instead of forcing in a fixnum with the %%KBD-MOUSE bit on, it sends a blip so that it can send the X and Y positions also. It is unfortunate that I have to copy all the rest of the code besides the last line. I suggest that we replace the existing message with a :MOUSE-BUTTONS-RAW message, and replace the last line of its handler with a FUNCALL-SELF MOUSE-BUTTONS. Then a random user can install a simple handler, and things like the activity time and the calling of the system menu and the selection process will all happen automatically, without everyone having to copy the code all the time. If nobody objects, I will do this.  Date: 23 October 1980 00:45-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 46.1, with microcode 692, on LISP Machine Six: When the system cold-boots, there are all these initial windows, like the Zmail and Supdup and Peek windows. It is nice for these to be around, so that the System key and the Select menu can get at them, but it is a pain that when you start playing with the window editor, they appear on your screen; you innocently start reshaping things, and little pieces of Zmail menus and stuff like that start appearing underneath even though you never expressed any interest in Zmail at all. It would be nice if they were not actually visible, but you could still invoke them from System-X and the Select menu. I am not sure just what to do about this. Dave suggested giving these windows negative screen-manager priorities, and having some way that the priority gets reset to normal as soon as you use the window. This may be the right thing: a state of being active but not visible. I don't know...  Date: 21 October 1980 23:06-EDT From: Mike McMahon Sender: MMcM at CADR6 at MIT-AI To: DLW at MIT-AI cc: BUG-NWS at MIT-AI Date: 19 October 1980 16:18-EDT From: Daniel L. Weinreb ZWEI problem: control-meta-F moves forward over this thing fine, but c-m-B feeps. c-m-P works. There are no comments or strings or anything funny. See my RMAIL file. [Wait a minute, there were double-quotes around the whole thing, that is probably why it failed. But then why did c-m-F work? Does only c-m-B use f-control-f?] One problem is that there is an odd number of |'s in the table. C-M-F can work, since lisp parsing is a forward process. C-M-B works by parsing forward from some a known point and saving state. If the (DEFUN had been at the start of a line, it would not have have been confused. ZWEI problem or NWS problem: When it was done, blocked with "Sheet Deexp" on the who-line. Not being in the mood to try to fix this, I just clicked on the main window with the function in it. This is just that it was trying to expose the typeout window to tell you of an error. The pop-up window would have gone away if the typeout window had gotten selected properly. Possible NWS problem: while I was in the error handler for the above, the blinker was in ON state rather than BLINK state. Is this one of those problems about frames and selection not working together? This is the same selection problem.  Date: 21 October 1980 18:03-EDT From: Mike McMahon Sender: MMcM at CADR7 at MIT-AI To: MOON at MIT-AI cc: BUG-NWS at MIT-AI Moon@MIT-AI 10/21/80 02:04:32 Do you know of a bug where the :NAME-FOR-SELECTION of a Zmacs frame could momentarily be NIL? That's the only reason I can think of why sometimes SYSTEM E gives a new frame rather than going to the existing one (this is in 46.1). It happens at times like if I tell it to start writing out my files (with the multiple-choose) then switch to a supdup or something then type SYSTEM E a long time later. I cannot find any circumstance in which that could happen. I have seen cases where a frame that has been selected many times before fails to appear in the array of previously-selected windows if you go to another program when it is running like that, although i have not been able to track it down.  Date: 21 October 1980 17:26-EDT From: Mike McMahon Sender: MMcM at CADR7 at MIT-AI Subject: [RWG at MIT-MC: enspiffiments(?) of mice and men(us)] To: BUG-NWS at MIT-AI RWG@MIT-MC 10/20/80 08:30:55 Re: enspiffiments(?) of mice and men(us) To: (BUG ZWEI) at MIT-MC considerable enhancement in predictability would result if menu items that will request mouse selections (with cross-hairs or corner-brackets, e.g.) were to show the cursor(s) in the menu next to the item-name. and the cursor for KILL ought to be a skull-and-crossbones instead of the over-used cross- hairs. (and maybe you could pop up a small, self-destructing clay-pigeon window to kill, in case i didn't mean to be killing anything after all.) i suggested to rms that depressing >1 mousebutton while in a menu could stick the menu to the mouse-motion, and he counterproposed that it be just another menu item. i amend this to be an iconographic handle at the top of the menu, which becomes grabbed by an iconographic hand while it is being dragged around with a mousebutton held down, reverting to a fixed menu with arrow cursor when you release the button. also, i have gotten a variable-lenght menus of length one. if a menu item will result in a very short new menu, then (i think) the new menu item(s) should have appeared instead in the previous menu. e.g. if you bug Shatter Window (Select) and get a new menu with only Port-Hole, you should have been offered Shatter Port-Hole in the first place.  MOON@MIT-MC 10/20/80 23:29:58 To: dlw at MIT-AI CC: (BUG ZWEI) at MIT-AI, (BUG nws) at MIT-AI Date: 20 October 1980 01:02-EDT From: Daniel L. Weinreb Sender: dlw at CADR6 at MIT-AI To: BUG-ZWEI at MIT-AI In the version of ZWEI on system 46.1, with microcode 692, on LISP Machine Six: If you do a Describe Flavor, type in some characters, hit ? (producing a set of possible completions), mouse one, start reading the blurb, and hit spaces to page through it, the area that you moused remains mouse-sensitive and a big black blob insists on appearing there as long as you don't move the mouse away, even though there isn't anything there for it to highlight any more. The bug is that at the instant it types over a mouse-sensitive item it doesn't wake up the mouse process so it can notice the mouse is gone. This is hard to fix since every message to the window that could type out would have to wake up the mouse process. Note that the blob disappears as soon as you pound on the table and wiggle the mouse. Any ideas?  Date: 20 OCT 1980 2150-EDT From: Moon at MIT-AI (David A. Moon) Subject: Small system change To: (BUG NWS) at MIT-AI CC: DLW at MIT-AI I added SCREEN-MANAGE-PARTIALLY-VISIBLE-MIXIN, which makes a window be visible when it is partially exposed even if it has no bit save array. (The default is to have such windows fully disappear). Possibly we want to change the default and make a mixin that does what the default is now.  Date: 18 October 1980 14:51-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 46.1, with microcode 692, on LISP Machine Eight: I just got screwed by a weird timing problem. Here is what happened. (1) I was in ZMACS, taking up the whole screen, and typed m-X View Directory, and gave it its argument. It proceeded to try to open the DIR device, etc. (2) While it was thinking, I got a qsend. I answered and typed End. (3) The ZMACS continued normally, and I viewed the directory. When it got to the end I typed a space to flush the typeout window and continue editing. (4) But, what happened it that the typeout window disappeared to reveal the QSEND window, with the message and my reply in it, sitting there blinking. The wholine said STOP. (5) Well, I figured it just screwed up which window was above and below which window, and I wanted the editor, which was now partially visible since the QSEND window is only at the top of the screen. So it did a single-click-left on it. (6) Nothing happened! The wholine went to Lock. (7) So I figured it was waiting for a lock for some reason, but I didn't know why. I tried Terminal Control-Clear-Input. (8) The typeout window with the last screenful of the directory I was viewing reappeared, and then the editor bombed out in the ZMACS-MODE-LINE-WINDOW-MIXIN's :BEFORE ;REFRESH method, at PC = 54, with NIL as the first arg to <. Control-Zing this error just made it happen again.  MOON@MIT-MC 10/16/80 23:17:42 Re: Making GET-HANDLER-FOR a message To: dlw at MIT-AI CC: RWG at MIT-MC, (BUG NWS) at MIT-AI Date: 16 October 1980 14:13-EDT From: Daniel L. Weinreb Sender: dlw at CADR7 at MIT-AI Subject: Making GET-HANDLER-FOR a message To: RWG at MIT-MC cc: BUG-NWS at MIT-AI Well, I understand everyone's objections, and agree that we need to keep get-handler-for since sometimes you can be calling it on things that might not take messages at all. But it still seems to me that in a message passing system it is highly natural to have a "do you understand this message" message, and I don't think it would get in anyone's way. The proposed name for the message is :GET-HANDLER-FOR, and if nobody objects I will add it to VANILLA-FLAVOR. Wait a minute, "do you understand this message" is different from "give me your method for this message" so I can call it in a special magic way. The former is (MEMQ msg (FUNCALL object ':WHICH-OPERATIONS)). If you really want the latter I don't object, but I don't see the point. This is not a pure message-passing system.  Date: 16 October 1980 14:13-EDT From: Daniel L. Weinreb Sender: dlw at CADR7 at MIT-AI Subject: Making GET-HANDLER-FOR a message To: RWG at MIT-MC cc: BUG-NWS at MIT-AI Well, I understand everyone's objections, and agree that we need to keep get-handler-for since sometimes you can be calling it on things that might not take messages at all. But it still seems to me that in a message passing system it is highly natural to have a "do you understand this message" message, and I don't think it would get in anyone's way. The proposed name for the message is :GET-HANDLER-FOR, and if nobody objects I will add it to VANILLA-FLAVOR.  MOON@MIT-MC 10/15/80 20:17:48 Re: Making GET-HANDLER-FOR a message To: RWG at MIT-MC, dlw at MIT-AI CC: (BUG NWS) at MIT-AI Like Howard, I don't see any point to doing so. It's not something you would ever want to redefine, and you need a non-message way of doing it anyway so you can get back NIL when you apply the operation to a non-message-receiving object.  Date: 15 October 1980 18:07-EDT From: Howard I. Cannon To: dlw at MIT-AI cc: BUG-NWS at MIT-AI, RWG at MIT-AI Well, I guess I don't see what's wrong with GET-HANDLER-FOR, which presumably does the right thing for any lisp object, but I of course have no objections to sticking in another message. After all, how can it affect anyone?  Date: 15 October 1980 16:40-EDT From: Daniel L. Weinreb Sender: dlw at CADR7 at MIT-AI To: BUG-NWS at MIT-AI cc: RWG at MIT-AI In the version of NWS on system 46.1, with microcode 692, on LISP Machine Seven: (This is actually about flavors, not the NWS, sorry.) What do people think about adding a handler to vanilla-flavor for a message that means "do you support this operation"? Actually, all I want is a messge that every object supports that invokes the get-handler-for function. It just seems cleaner to do it with a method. RWG suggested this and I agree.  Date: 15 OCT 1980 0133-EDT From: dlw at MIT-AI (Daniel L. Weinreb) Sent-by: ___043 at MIT-AI To: (BUG NWS) at MIT-AI There should be some easier ways for people to do thing to the blinker of a window. I know there can be several, but usually there is only one... I particularly want an easy way to lambda-bind the blinker's visibility to NIL (this needs an unwind-protect of course). Maybe it should bind off all of them, or something. But there really should be an easy way to do this for naive uses.  Date: 14 OCT 1980 2342-EDT From: Moon at MIT-AI (David A. Moon) To: (BUG NWS) at MIT-AI There was a bug caused by the fact that frames do not include ESSENTIAL-MOUSE; if you point at the border of a frame that has one and click the middle button, you get a no handler for :DOCUMENT error. I fixed this by flushing the :DOCUMENT message, which should have been flushed long ago. Note that this now means that menus treat all mouse buttons alike. I wonder if there are any other bugs due to frames not including ESSENTIAL-MOUSE. I do not see any obvious ones from looking at the code.  Date: 14 OCT 1980 2050-EDT From: MMcM at MIT-AI (Mike McMahon) To: JLK at MIT-MC CC: BSG at MIT-AI, (BUG NWS) at MIT-AI According to what this ARPANET protocol handbook says, what Multics does is correct. CR LF is the NVT ASCII newline character, it means move to the start of the next line, and is operating system dependent. Some systems may implement this by two separate characters, like most terminals, one that moves to the start of the line, and one that advances the line, but they need not. Up until now the LISP machine only supported the "single character" version. CR NUL is how you send a bare carriage return in NVT ASCII, if the terminal and user operating system can support it. I have fixed up the change you made to the BUFFERED-TYO method in accordance with this. This also means that the :INCREMENT-CURSORPOS method is not needed, though i fixed it and left it around too. You might want to fix Plasma to do newline for CR LF and bare carriage return for CR NUL. Theoretically, nothing else is allowed after a CR, but it is obvious what to do in any other case anyway.  Date: 13 OCT 1980 1404-EDT From: BAK at MIT-AI (William A. Kornfeld) To: (BUG NWS) at MIT-AI In system 44.3, the Inspector If an item in the History pane is pointed to directly (so that its boxed) and mouse-middle is pressed, an error occurs. Even if this is not supposed to do anything useful, it should do something innocuous like beeping.  Date: 13 OCT 1980 0039-EDT From: Moon at MIT-AI (David A. Moon) Subject: Gratuitous changes To: (BUG NWS) at MIT-AI I changed MOMENTARY-MENU (and hence all the other momentary menu flavors) to use TOP-BOX-LABEL-MIXIN rather than TOP-LABEL-MIXIN because the latter looks terrible in a pop-up window. This is the flavor that MENU-CHOOSE uses. I change ZWEI:MAKE-MENU-COMMAND and its callers to have a symbolic name for its system-window type rather than using a gensym.  Date: 8 OCT 1980 0210-EDT From: Moon at MIT-AI (David A. Moon) To: (BUG NWS) at MIT-AI In the version of NWS on system 44.4 Daedalus, with microcode 692, on LISP Machine Two: In this system when you warm-boot or disk-restore, the warm-boot message comes out then is instantly erased and replaced by the greeting message. I'm not sure why. Someone should make sure this doesn't happen in the standard 46.1 or fix it if it does, I would myself but I'm busy at the moment.  MOON@MIT-MC 10/06/80 21:10:42 To: MMCM at MIT-AI CC: (BUG NWS) at MIT-AI Date: 6 OCT 1980 1539-EDT From: MMCM at MIT-AI (Mike McMahon) To: (BUG NWS) at MIT-AI SELECT-SHEET should somehow set A-TV-SCREEN-BUFFER-END-ADDRESS to be the address of the end of the sheet, not of the array, which due to indirection is almost always the bottom of the screen. If the arrays are set up properly they should be no longer than the sheet; while the array indirected-to is longer the one indirecting has its own length field which can be shorter. Ah, but there is a bug in the array microcode! I will go fix it in the source.  Date: 6 October 1980 20:11-EDT From: Daniel L. Weinreb Sender: dlw at CADR7 at MIT-AI To: HIC at MIT-MC cc: BUG-NWS at MIT-AI Hmm. Yes, Terminal Clear-Screen does do that already. I don't understand exactly whether it is undocumented or whether I saw it but it didn't register or something. Sigh.  Date: 6 October 1980 15:54-EDT From: Howard I. Cannon To: dlw at MIT-AI cc: BUG-NWS at MIT-AI Date: 6 October 1980 15:28-EDT From: Daniel L. Weinreb To: BUG-NWS at MIT-AI Terminal Clear-Screen is not being used now, is it? If not, how about making it a command to send a :REFRESH message to the whole screen (or to all the screens)? I've needed this sometimes. Doesn't it do this already? Perhaps it isn't documented.  Date: 6 OCT 1980 1539-EDT From: MMCM at MIT-AI (Mike McMahon) To: (BUG NWS) at MIT-AI SELECT-SHEET should somehow set A-TV-SCREEN-BUFFER-END-ADDRESS to be the address of the end of the sheet, not of the array, which due to indirection is almost always the bottom of the screen.  Date: 6 OCT 1980 1528-EDT From: dlw at MIT-AI (Daniel L. Weinreb) To: (BUG NWS) at MIT-AI Terminal Clear-Screen is not being used now, is it? If not, how about making it a command to send a :REFRESH message to the whole screen (or to all the screens)? I've needed this sometimes.  Date: 6 October 1980 12:05-EDT From: Daniel L. Weinreb Sender: dlw at CADR6 at MIT-AI To: BUG-NWS at MIT-AI OK, I guess that experience with the Screen editor Expand All command was just a coincidence, since I cannot reproduce it.  Date: 5 OCT 1980 2205-EDT From: dlw at MIT-AI (Daniel L. Weinreb) To: (BUG NWS) at MIT-AI In the Screen Editor, Expand All seems to mean that the fully exposed windows get expanded to fill the whole screen. Howver, I think I just saw a case in which the decision of how to split up the remainder of the screen was influenced by the edge of a partially-exposed window. This seems rather non-obvious; it seems like that algorithm ought to only depend on the current edges of the fully exposed windows.  Date: 5 OCT 1980 1933-EDT From: dlw at MIT-AI (Daniel L. Weinreb) To: (BUG NWS) at MIT-AI When you create a window on the color screen, and give :edges-from ':mouse, and the mouse is on the main screen, it seems to bomb out. It should move the mouse to the color screen for the duration and work properly.