From: Mike McMahon <MMcM at MIT-AI>
To: BUG-NWS at MIT-AI
Date: 9 June 1981 00:55-EDT

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 <Moon at MIT-AI>
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 <hic at MIT-AI>
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 <HIC at MIT-MC>
To: rms at MIT-AI
cc: BUG-NWS at MIT-AI

    Date: 5 June 1981 02:34-EDT
    From: Richard M. Stallman <rms at MIT-AI>
    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 <rms at MIT-AI>
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 <MMcM at MIT-AI>
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 <HIC at MIT-MC>
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 <JMTURN at MIT-AI>
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 <Moon at MIT-AI>
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 <MMcM at MIT-AI>
    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 <MMcM at MIT-AI>
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 <MMcM at MIT-AI>
    
    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 <MMcM at MIT-AI>
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 <JERRYB at MIT-AI>
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 <dlw at MIT-AI>
	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 <Moon at MIT-AI>
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 <dlw at MIT-AI>
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 <RWK at MIT-MC>
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 <dlw at MIT-AI>
    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 <dlw at MIT-AI>
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 <dlw at MIT-AI>
    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 <dlw at MIT-AI>
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 <dlw at MIT-AI>
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 <HIC at MIT-MC>
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 <RWK at MIT-MC>
    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 <JERRYB at MIT-AI>
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 <MMcM at MIT-AI>
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 <MMcM at MIT-AI>
To: DLW at MIT-AI
cc: BUG-NWS at MIT-AI

    Date: 9 May 1981 00:57-EDT
    From: Daniel L. Weinreb <dlw at MIT-AI>
    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 <MMcM at MIT-AI>
To: BUG-NWS at MIT-AI

    Date: 10 May 1981 01:46-EDT
    From: Henry Lieberman <Henry at MIT-AI>
    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 <JERRYB at MIT-AI>
To: JMTURN at MIT-AI
cc: BUG-NWS at MIT-AI

    Date: 9 May 1981 01:30-EDT
    From: James M. Turner <JMTURN>

    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 <JMTURN at MIT-AI>
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 <MMcM at MIT-AI>
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 <DLA at MIT-EECS>
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 <HIC at MIT-MC>
    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 <HIC at MIT-MC>
To: DLA at MIT-AI
cc: BUG-NWS at MIT-AI

    Date: 3 May 1981 03:03-EDT
    From: David L. Andre <DLA at MIT-AI>
    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 <DLA at MIT-AI>
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 <HIC at MIT-MC>
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 <DLW at MIT-AI>
    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 <CWH at MIT-MC>
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 <DLW at MIT-AI>
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 <JerryB at MIT-AI>
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 <RWK at MIT-MC>
    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 <MMCM at MIT-AI>
	To: CWH at MIT-MC
	cc: BUG-NWS at MIT-AI
	
	    Date: 30 April 1981 02:23-EST
	    From: Carl W. Hoffman <CWH at MIT-MC>
	    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 <MMcM at MIT-XX>
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 <RWK at MIT-MC>
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 <MMCM at MIT-AI>
    To: CWH at MIT-MC
    cc: BUG-NWS at MIT-AI
    
	Date: 30 April 1981 02:23-EST
	From: Carl W. Hoffman <CWH at MIT-MC>
	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 <JERRYB at MIT-AI>
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 <MMCM at MIT-AI>
To: CWH at MIT-MC
cc: BUG-NWS at MIT-AI

    Date: 30 April 1981 02:23-EST
    From: Carl W. Hoffman <CWH at MIT-MC>
    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 <CWH at MIT-MC>
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 <dlw at MIT-AI>
To: BUG-NWS at MIT-AI, CWH at MIT-MC

    Date: 28 April 1981 19:09-EST
    From: Carl W. Hoffman <CWH at MIT-MC>
    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 <CWH at MIT-MC>
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 <MMCM at MIT-AI>
To: DLW at MIT-AI
cc: BUG-NWS at MIT-AI

    Date: 24 April 1981 16:24-EST
    From: Daniel L. Weinreb <dlw at MIT-AI>
    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 <dlw at MIT-AI>
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 <DLW at MIT-AI>
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 <PINES at MIT-AI>
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 <MMcM at MIT-AI>
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 <dlw at MIT-AI>
To: MOON at MIT-AI
cc: BUG-NWS at MIT-AI

    Date: 18 April 1981 03:23-EST
    From: David A. Moon <Moon 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.

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 <dlw at MIT-AI>
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 <Moon at MIT-AI>
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 <Moon at MIT-AI>
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 <Moon at MIT-AI>
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 <WALKER at MIT-AI>
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 <Moon at MIT-AI>
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 <PINES at MIT-AI>
    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 <MMcM at MIT-AI>
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 <CWH at MIT-MC>
    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 <MMcM at MIT-AI>
To: KENT at MIT-AI
cc: BUG-NWS at MIT-AI

    Date: 15 April 1981 09:41-EST
    From: Kent A. Stevens <KENT at MIT-AI>
    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 <CWH at MIT-MC>
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 #<PROCESS Mouse ...> 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 <CWH at MIT-MC>
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 <PINES at MIT-AI>
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 <PINES at MIT-AI>
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 <CWH at MIT-MC>
    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 <CWH at MIT-MC>
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 <CWH at MIT-MC>
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 <cwh at MIT-MC>
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 <CWH at MIT-MC>
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 <CWH at MIT-MC>
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 <MMcM at MIT-AI>
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 <RWK at MIT-MC>
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 <dlw at MIT-AI>
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 <ALAN at MIT-MC>
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 <dlw 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?

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 <dlw at MIT-AI>
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 <RWK at MIT-MC>
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 <RWK at MIT-MC>
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 <DLA at MIT-EECS>
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 <DLW at MIT-AI>
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 <RWK at MIT-MC>
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 <DLW at MIT-AI>
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 <DLW at MIT-AI>
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 <HIC at MIT-MC>
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 <MMcM at MIT-AI>
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 <HIC at MIT-MC>
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] <arg> C complementing the mouse documentation line?

Date: 16 March 1981 19:05-EST
From: Jonathan D. Taft <TAFT at MIT-MC>
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 <RWK at MIT-MC>
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 <dlw at MIT-AI>
    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 <CWH at MIT-MC>
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))
#<BORDERED-CONSTRAINT-FRAME-WITH-SHARED-IO-BUFFER BORDERED-CONSTRAINT-FRAME-WITH-SHARED-IO-BUFFER-4 5433605 exposed>
(funcall temp ':kill)    ;the window is still there
#<DTP-LOCATIVE 5405406>
)
(setq temp2 (create-new-window))
#<BORDERED-CONSTRAINT-FRAME-WITH-SHARED-IO-BUFFER BORDERED-CONSTRAINT-FRAME-WITH-SHARED-IO-BUFFER-5 5434027 exposed>

(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 <dlw at MIT-AI>
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 <DLW at MIT-AI>
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 <DLW at MIT-AI>
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 <RWK at MIT-MC>
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 <MMcM at MIT-AI>
    ....
						      (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 <dlw at MIT-AI>
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 <dlw at MIT-AI>
    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 <MMcM at MIT-AI>
To: DLW at MIT-AI
cc: BUG-NWS at MIT-AI

    Date: 11 March 1981 22:39-EST
    From: Daniel L. Weinreb <dlw 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 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 <MMcM at MIT-AI>
To: DLW at MIT-AI
cc: BUG-NWS at MIT-AI

    Date: 11 March 1981 22:35-EST
    From: Daniel L. Weinreb <dlw at MIT-AI>
	Date: 11 March 1981 15:12-EST
	From: Mike McMahon <MMcM 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.
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 <dlw at MIT-AI>
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 <dlw at MIT-AI>
To: MMCM at MIT-AI, BUG-NWS at MIT-AI

    Date: 11 March 1981 15:12-EST
    From: Mike McMahon <MMcM at MIT-AI>
    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 <dlw at MIT-AI>
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 <MMcM at MIT-AI>
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 <MMcM at MIT-AI>
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 <DLW at MIT-AI>
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 <RWK at MIT-MC>
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 <HIC at MIT-MC>
To: MMcM at MIT-AI
cc: BUG-NWS at MIT-AI

    Date: 2 March 1981 16:45-EST
    From: Mike McMahon <MMcM at MIT-AI>
    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 <HIC at MIT-MC>
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 <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 <HIC at MIT-MC>
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 <HIC at MIT-MC>
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 <MMcM at MIT-AI>
    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 <MMcM at MIT-AI>
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 <HIC at MIT-MC>
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 <cntrl>-abort aborted a <terminal><n>F
instead of restarting it.

Date: 19 February 1981 12:28-EST
From: Howard I. Cannon <HIC at MIT-MC>
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 <Moon at MIT-AI>
    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 <dlw at MIT-AI>
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 <MMcM at MIT-AI>
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 <MMcM at MIT-AI>
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 <window> 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 <dlw at MIT-AI>
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 <dlw at MIT-AI>
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 <MMcM at MIT-AI>
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 <RWK at MIT-MC>
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 <dlw at MIT-AI>
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 <MMcM at MIT-AI>
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 <MMcM at MIT-AI>
To: BUG-NWS at MIT-AI
cc: DLW at MIT-AI

    Date: 2 February 1981 02:31-EST
    From: Daniel L. Weinreb <dlw at MIT-AI>
    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 <dlw at MIT-AI>
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 <dlw at MIT-AI>
To: BUG-NWS at MIT-AI
cc: JERRYB at MIT-AI

    Type <system><help> 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 <space> 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 <dlw at MIT-AI>
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 <system><help> 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 <MMcM at MIT-AI>
To: RWK at MIT-MC
cc: BUG-NWS at MIT-MC

    Date: 28 January 1981 07:22-EST
    From: Robert W. Kerns <RWK at MIT-MC>
    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 <MMcM at MIT-AI>
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 <terminal>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.  <terminla><cntl><clear-input>
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 <system><help> then space.  The window takes about 5 seconds to go away.

Date: 28 January 1981 07:22-EST
From: Robert W. Kerns <RWK at MIT-MC>
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 <dlw at MIT-AI>
To: JERRYB at MIT-AI, BUG-NWS at MIT-AI

    After doing an (inspect <object>) <cntrl>-Z works to get back to the lisp-listener but
    <abort> 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 <object>) <cntrl>-Z works to get back to the lisp-listener but
<abort> does not.

Date: 26 January 1981 12:31-EST
From: Mike McMahon <MMcM at MIT-AI>
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 <system>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 <MMcM at MIT-AI>
Subject: WINDOC
To: DLW at MIT-AI
cc: BUG-NWS at MIT-AI

    Date: 26 January 1981 01:42-EST
    From: Daniel L. Weinreb <dlw at MIT-AI>
    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 <dlw at MIT-AI>
    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 <dlw at MIT-AI>
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 <HIC at MIT-MC>
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 <dlw at MIT-AI>
    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 <dlw at MIT-AI>
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 <dlw at MIT-AI>
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 <MMcM at MIT-AI>
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 <dlw at MIT-AI>
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 <MMcM at MIT-AI>
    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 <dlw at MIT-AI>
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 <JLK at MIT-MC>
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 <dlw at MIT-AI>
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 <dlw at MIT-AI>
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 <BEE at MIT-AI>
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 <ABORT>.
    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 <ABORT>.
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 <DLA at MIT-AI>
    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 <dlw at MIT-AI>
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 <dlw at MIT-AI>
    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 <DANIEL at MIT-AI>
    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 <dlw at MIT-AI>
    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 <dlw at MIT-AI>
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 <dlw at MIT-AI>
    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 <Moon at MIT-AI>
    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 <dlw 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.
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 <CPR at MIT-AI>
    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 <Moon at MIT-AI>
    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 <Moon at MIT-AI>
    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 <MMcM at MIT-AI>
    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 <dlw at MIT-AI>
	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 <JERRYB at MIT-AI>
    To: DLW at MIT-AI
    cc: BUG-NWS at MIT-AI
    
	Date: 11 December 1980 02:46-EST
	From: Daniel L. Weinreb <dlw>
	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 <dlw at MIT-AI>
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 <MMcM at MIT-AI>
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 <dlw at MIT-AI>
    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 <JERRYB at MIT-AI>
To: DLW at MIT-AI
cc: BUG-NWS at MIT-AI

    Date: 11 December 1980 02:46-EST
    From: Daniel L. Weinreb <dlw>
    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 <dlw at MIT-AI>
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 <dlw at MIT-AI>
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 <MMcM at MIT-AI>
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 <dlw at MIT-AI>
    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 <dlw at MIT-AI>
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 <MMcM at MIT-AI>
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 <BEE at MIT-AI>
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 <dlw at MIT-AI>
    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 <dlw at MIT-AI>
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 <dlw at MIT-AI>
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 <dlw at MIT-AI>
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 <BEE at MIT-AI>
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 <dlw at MIT-AI>
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 <dlw at MIT-AI>
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 <dlw at MIT-AI>
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 <DLA at MIT-EECS>
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 <dlw at MIT-AI>
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 <DLW at MIT-AI>
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 <DLA at MIT-EE>
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 <MMcM at MIT-AI>
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 <MMcM at MIT-AI>
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 <HIC at MIT-MC>
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 <dlw at MIT-AI>
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 <dlw at MIT-AI>
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 <dlw at MIT-AI>
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 <DLA at MIT-EE>
    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 <HIC at MIT-MC>
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 <dlw at MIT-AI>
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 <dlw at MIT-AI>
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 <dlw at MIT-AI>
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 <HIC at MIT-MC>
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 <HIC at MIT-MC>
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 <JERRYB at MIT-AI>
    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 <MMCM at MIT-AI>
        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 <dlw at MIT-AI>
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 <dlw at MIT-AI>
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 <JERRYB at MIT-AI>
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 <MMCM at MIT-AI>
    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 <JERRYB at MIT-AI>
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 <HIC at MIT-MC>
    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 <HIC at MIT-MC>
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 <MMcM at MIT-AI>
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 <MMCM at MIT-AI>
To: DLW at MIT-AI
cc: BUG-NWS at MIT-AI

    Date: 2 November 1980 01:02-EST
    From: Daniel L. Weinreb <dlw at MIT-AI>
    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 <dlw at MIT-AI>
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 <HIC at MIT-MC>
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 <HIC at MIT-MC>
Subject: Top level binding of TERMINAL-IOTo: Daniel L. Weinreb <dlw at MIT-AI>
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 <dlw at MIT-AI>
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 <dlw at MIT-AI>
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 <dlw at MIT-AI>
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 <MMcM at MIT-AI>
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 <HIC at MIT-MC>
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 <MMcM at MIT-AI>
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 <dlw at MIT-AI>
    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 <HIC at MIT-MC>
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 <Moon at MIT-AI>
    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 <HIC at MIT-MC>
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 <MOON5 at MIT-AI>
    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 <HIC at MIT-MC>
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 <dlw at MIT-AI>
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 <HIC at MIT-MC>
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 <dlw at MIT-AI>
    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 <HIC at MIT-MC>
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 <dlw at MIT-AI>
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 <HIC at MIT-MC>
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 <dlw at MIT-AI>
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 <dlw at MIT-AI>
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 <HIC at MIT-MC>
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 <HIC at MIT-MC>
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 <dlw at MIT-AI>
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 <dlw at MIT-AI>
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 <MMcM at MIT-AI>
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 <dlw at MIT-AI>
    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 <MMcM at MIT-AI>
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 <MMcM at MIT-AI>
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 <dlw at MIT-AI>
    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 <dlw at MIT-AI>
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 <dlw at MIT-AI>
    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 <dlw at MIT-AI>
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 <HIC at MIT-MC>
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 <dlw at MIT-AI>
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 <dlw at MIT-AI>
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 <HIC at MIT-MC>
To: dlw at MIT-AI
cc: BUG-NWS at MIT-AI

    Date: 6 October 1980 15:28-EDT
    From: Daniel L. Weinreb <dlw at MIT-AI>
    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 <dlw at MIT-AI>
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.