Nuprl's windows are at the ``top-level'' in the X environment. The windows can be managed (positioned, sized, etc.) in the same way as other top-level applications such as X-terminals. Creation and destruction of Nuprl windows, and manipulation of window contents, is done solely via commands interpreted by Nuprl. Nuprl will receive mouse clicks and keyboard strokes whenever the the input focus is on any of its windows. Exactly one window is ``active'' at any given time; this window is identified by the presence of Nuprl's cursor. This appears either as a vertical bar or as a highlighted region. The specific location of the cursor determines the semantics of keyboard strokes and mouse clicks, and is independent of the location of the mouse cursor.
The two main windows --- the ML-Top-Loop
window!ML-Top-Loop
} and the library
window --- remain throughout the session and you cannot create new
versions of them. Chapter 
describes use of the ML-Top-Loop
\
window and Chapter
describes the format of the library window.
Chapter
also describes the kinds of objects that can
be found in the library.
There are two other kinds of windows; term editor windows and
proof editor windows . Both are used for editing objects in the
library. Terms and the term editor is described in Chapter
and
the proof editor is described in Chapter
.
Most Lisps allow computations to be interrupted . This is usually done
by sending 
C-C
to the Lisp process. (If Lisp is started up from
an emacs sub-shell, you usually can do this by typing 
C-C
C-C
to the sub-shell window). This will cause Lisp to enter its debugger
,
from which the computation can be resumed or aborted. Aborting Nuprl
is almost always safe. When Nuprl is restarted, the state should be
exactly as it was when Nuprl was killed, except that any computations
within Nuprl will have been aborted.
See Chapter
for how to use the Lisp debugger, and in
particular, for what to if Nuprl
crashes. Nuprl
is a
continually-evolving experimental research system, and it is
inevitable that it will contain bugs. Please report any behavior you
think is due to a bug, or inconsistencies between the operation of the
system and the documentation. Also report any break-points that you
hit; they have either been left in the code accidentally, or they are
there to help track down the source of bugs. We welcome suggestions
for improvement. Send e-mail to nuprlbugs @cs.cornell.edu.
If the system appears to be inexplicably stuck, check the window running Lisp; it is very possible that Lisp is garbage-collecting . This sometimes takes a few minutes.