🚀 go-pugleaf

>From JWALKER@BBNA Sun Jul  5 09:34:06 1981
I don't follow the relevance of all this talk about "state
diagrams" in the discussion of resuming a suspended activity.
The human side of resuming something involves answering the
question "Now, where was I?".  One very effective answer to
that question is the screen display of the task as it was
when you left it.  (It is perhaps not the best answer, but
the best answer involves some meta-knowledge of what you
thought you were doing and your intentions for the various
commands you had used.  I am willing to assume that someone
can recognize what they were doing given the set of commands
they had issued before stopping work.)

I concur that the approach taken by the LISP machine and other
multi-window systems (that keep track of various process objects
and reinstate their displays when the objects are selected) is
correct.  These systems typically provide two ways of picking up
a dropped ball -- by using a mouse to select one of the objects
whose window is currently visible on the screen, and by using
a mouse to select an object from a menu window that contains a
brief description of each of the objects.  The menu gives you
complete context for "where was I?" by showing all of things you
are juggling.  This is very important because the fewer details
you have to keep in your head about what you are doing, the more
head is left over for actually getting the work done...  

Simply resuming a dropped activity should not be a problem
solving activity ("now, let's see, I think I had that running
as a kept fork under Hermes, which is running as a kept fork
under EMACS...").  The "multi-forking" TOPS-20 execs that exist
at several places (e.g. MIT, Stanford, Rutgers) also support
users who need to move "sideways" to do a task although TOPS-20
doesn't provide anything in the way of reinstating the display
context.

-----