I've got a Symbolics XL1200 at home running Genera 8.3, so I'll pitch
in what I can.  I'm not sure how any of this fits in (or could be made
to fit in) to Squeak, since the underlying application models are so
different, but here goes...

Brian Rice writes:
 > <Help>
 > 	This command-line documentation hook works on EVERYTHING. If 
 > you hold down any key combination or partial combination, hitting 
 > <Help> calls up docs. The same works if you type in only partial 
 > keywords (argument selectors) for commands. This is incredibly 
 > universal.
 > <Complete>
 > 	Auto-completion par excellance. <Meta>-<Complete> yields a 
 > form to fill out, usable with a mouse. Even with forms, everything in 
 > the listener history is saved as listener commands only.
 > 
 > Now, the Lisp Listener is different in flavor from Smalltalk 
 > environments in the usual commercial implementations, but in Genera, 
 > it lends itself to the MVC way of user-interaction:
 > http://kogs-www.informatik.uni-hamburg.de/~moeller/symbolics-info/source-oriented-debugging.html
 > 
 > What's not obvious in a screen shot is how mousing over many parts of 
 > what appears to be a simple text display screen highlights parts of 
 > the text that act either as symbolic references (this seamlessly 
 > extends to hypertext it seems) or expressions/sub-expressions in 
 > code. Genera does everything in monochrome for programmers' 
 > efficiency over prettiness. So highlighting is a black box outline 
 > around text.
 > 
 > This is incredibly powerful, as it is highly context-sensitive. I 
 > imagine that modifier keys could actually access different contexts 
 > dynamically.


One of the things that makes the help and auto-complete facilities
possible in Genera is the command-driven GUI, which is quite different
from the event-driven mechanism used in Squeak.  While this is most
visible in the Command Processor/Listener, all applications have their
own command processor.  The application is responsible for translating
mouse and keyboard events into these commands.

For those who have never used Genera, I'll give a quick example.  One
command is 'Edit File <file>'.  You can type this at the command
processor, and when you hit the space after typing "File", all file
objects in the system hilight themselves to let you know they are
candidates.  Click on one, and Genera will stick the file object in
the command line.  Press return, and Genera executes the command.

OTOH, if you've recently executed the 'Show Directory <dir>' command,
you can first click on the file in the directory listing, pop up it's
menu, and pick the "Edit" option.  The file's menu object will send
the 'Edit File' command to the window's CP, with the appropriate file
filled in as the parameter.  The nifty thing about this is that it
allows both noun-verb or verb-noun style interactions; actually even
more complicated interactions are possible, since commands can be
multi-part.  Because commands know what types of objects are needed as
parameters, the system can prompt you either visually via hilighting
all applicable objects, or by popping up a menu of completions if you
hit the <Complete> key, or by popping up appropriate help if you hit
the <Help> key.

While it may seem that commands are just a cmdline thing, they are
much more pervasive than that because the application's "event loop"
such as it is is really a "command processor loop".  If you've got a
graphic editor, and you want to draw an arc between two nodes, you
could click on a node, pick the "connect" option off its menu, which
might submit the command "Connect Arc <thisnode> To <node>".  The
Command Processor would then prompt you for the second node, helpfully
hilighting all visible nodes for you.  You could press the <Complete>
key for a list of the recent nodes, or <Meta><Complete> for a list of
all nodes in the document.  Commands can also take optional and
keyword parameters, so you could issue the command 'Connect Arc
<node1> To <node2> :style :arrow :color :red :title "Foo"'.

This interaction model depends quite heavily on everything you see
being active, so executing a command or lisp function doesn't just
print out some text, it returns an active object (or set of objects)
that is appended to the listener session, but which can be further
manipulated.  For that matter, even the commands themselves are
active.  Mousing over a command or lisp expression will hilight it,
and its menu will give you a variety of actions you can perform on it.

Maybe some of these ideas could be incorporated into the Squeak
scripting systems, the CP-based model was certainly easily scriptable,
and the prompting, completion, and help systems would be quite helpful
for novices and younger programmers.


 > 
 > I'm not suggesting that this is useful directly, but there are 
 > certain aspects which are nice. For one, the presence of a listener 
 > is nice enough. If one were to do something similar in Squeak, it 
 > would likely involve the graphical production of Inspectors for the 
 > results and command forms. One aspect of the listener which Squeak 
 > could keep is the notion that a Listener session is a thread of 
 > activity, that it can spawn other threads, and keep the relationships 
 > explicit.
 > 
 > I have many ideas related to this, and I would suggest at least 
 > looking into how key bindings work in Squeak, and perhaps creating a 
 > suitable architecture for them before too many people rely on a 
 > system which is not modular enough.
 > 
 > What are your thoughts on this?
 > 
 > Thanks,
 > ~