Index: guided-tour.tex
===================================================================
RCS file: /project/mcclim/cvsroot/mcclim/Doc/Guided-Tour/guided-tour.tex,v
retrieving revision 1.1
diff -u -r1.1 guided-tour.tex
--- guided-tour.tex	30 Jan 2006 16:14:01 -0000	1.1
+++ guided-tour.tex	31 Jan 2006 13:27:19 -0000
@@ -2,6 +2,7 @@
 \usepackage[dvips]{graphicx}
 \usepackage{color}		% Need the color package
 \usepackage{listings}
+\usepackage{url}
 %\usepackage{epsfig}
 \title{\Huge A Guided Tour of CLIM, \\ Common Lisp Interface Manager}
 \author{
@@ -36,7 +37,9 @@
 \newcommand {\concept} [1] {{\sl #1}\index{#1}}
 \newcommand {\term} [1] {{\sl #1}}
 \newcommand {\code}[1]{{\sffamily #1}}
-\newcommand {\CLIM}{{\small CLIM}}
+\newcommand {\CLIM}{\textsc{clim}}
+\newcommand {\CLOS}{\textsc{clos}}
+\newcommand {\mcclim}{\textsc{McCLIM}}
 \let\class\code
 \let\method\code
 \let\constant\code
@@ -54,7 +57,7 @@
 output services, and mechanisms for constructing window types and user
 interface components; stream-oriented input and output facilities
 extended with presentations and context sensitive
-input\footnote{Similar to the work pioneered in the Genera UI system};
+input;\footnote{Similar to the work pioneered in the Genera UI system}
 and a gadget-oriented toolkit similar to those found in the X world
 extended with support for look and feel adaptiveness. In this article,
 we present an overview of \CLIM{}'s broad range of functionality and
@@ -62,25 +65,25 @@
 article originally appeared in Lisp Pointers in 1991 and was updated
 in 2006 by Clemens Fruhwirth.\footnote{The CLIM 2 specification
   changed significant parts of \CLIM{} rendering legacy code
-  unusable. Clemens Fruhwirth has rewritten all examples and the
-  corresponding text section for the \CLIM{} 2 specification. In
-  addition, he restructured the whole article and added text sections
+  unusable. Clemens Fruhwirth has rewritten all examples and the 
+  corresponding text sections for the \CLIM{} 2 specification. In
+  addition, he has restructured the whole article, adding sections
   to provide additional insights into \CLIM{} concepts.} All examples
-in this article have been developed with McCLIM{}\cite{mcclim}, a free
-\CLIM{} implementation.
+in this article have been run with \mcclim{}\cite{mcclim}, a free
+\CLIM{} implementation, as of January 2006.
 \end{abstract}
 
 \section*{Introduction}
 Common Lisp is a language standard that has provided a broad range of
 functionality, and that has, to a large degree, successfully enabled
-the writing of truly portable Lisp programs. The emergence of CLOS and
-the cleanup efforts of Ansi X3J13 have further enhanced the utility
+the writing of truly portable Lisp programs. The emergence of \CLOS{} and
+the cleanup efforts of ANSI X3J13 have further enhanced the utility
 and portability of Common Lisp. However, one major stumbling block
 remains in the path of those endeavoring to write large portable
 applications. The Common Lisp community has not yet provided a
 standard interface for implementing user interfaces beyond the most
 basic operations based on stream reading and printing.\footnote{Notice
-  that this sentence was written in 1991. Unfortunately, it is still
+  that this sentence was written in 1991; it is still
   true 15 years later.}
 
 The Common Lisp Interface Manager addresses this problem by specifying
@@ -92,7 +95,7 @@
 and high level facilities like context sensitive input, an adaptive
 toolkit, and an application building framework.
 
-\CLIM{} will eventually support a large number of window environments
+\CLIM{} implementations will eventually support a large number of window environments
 including X Windows, Mac OS X and Microsoft Windows. \CLIM{} is
 designed to exploit the functionality provided by the host environment
 to the degree that it makes sense. For example, \CLIM{} top level
@@ -100,17 +103,17 @@
 operations are ultimately performed by host window system
 code. Another example is that \CLIM{} supports the incorporation of
 toolkits written in other languages. A uniform interface provided by
-\CLIM{} allows Lisp applications programmers to deal only with Lisp
+\CLIM{} allows Lisp application programmers to deal only with Lisp
 objects and functions regardless of their operating platform.
 
-An important goal that has guided the design of \CLIM{} has been to
+An important goal that has guided the design of \CLIM{} was to
 layer the specification into a number of distinct
 facilities. Furthermore, the specification does not distinguish the
 use of a facility by higher level \CLIM{} facilities from its use by
 \CLIM{} users. For example, the geometry substrate, which includes
 transformations and regions, is designed for efficient use by the
-graphics and windowing substrates as well as by \CLIM{} users. This
-means that, in general, a \CLIM{} user can reimplement higher level
+graphics and windowing substrates as well as by \CLIM{} programmers. This
+means that, in general, a \CLIM{} programmer can reimplement higher level
 \CLIM{} facilities using the interfaces provided by lower level
 facilities.
 
@@ -123,19 +126,19 @@
 particular application.
 
 For example, \CLIM{}'s application framework and adaptive toolkit
-allow users to develop applications that automatically adopt the look
+allow programmers to develop applications that automatically adopt the look
 and feel of the host's environment. (We often call this
 ``adaptiveness,'' ``look and feel independence,'' or occasionally more
 picturesquely, ``chameleon look and feel''.) However, many users may
 need or want to define a particular look and feel that stays constant
-across all host environments (we call this "portable look and
-feel"). Such users can circumvent the look and feel adaptiveness
+across all host environments (we call this ``portable look and
+feel''). Such users can circumvent the look and feel adaptiveness
 provided by \CLIM{}, while still using most of the application
 framework facility and other high level \CLIM{} facilities like
 context sensitive input. Furthermore, using the lower level facilities
 of \CLIM{}, they can develop portable toolkit libraries that define
 and implement their own particular look and feel. For instance, the
-\CLIM{} user can implement new gadget types on top of the drawing
+\CLIM{} programmer can implement new gadget types on top of the drawing
 primitives and treat them equally to the build-in gadget types.
 
 We will use the term \concept{CLIM implementor} for the party
@@ -186,11 +189,11 @@
 \paragraph*{Formatted Output} \CLIM{} provides a set of high-level
 macros that enable programs to produce neatly formatted tabular and
 graphical displays easily.\footnote{This also includes Graph
-  Formatting}
+  Formatting.}
 
 \paragraph*{Presentations} \CLIM{} provides the ability to associate
 semantics with output, such that Lisp objects may be retrieved later
-via user gestures (e.g. mouse clicks) on their displayed
+via user gestures (e.g.{} mouse clicks) on their displayed
 representation. This context sensitive input is modularly layered on
 top of the output recording facility and is integrated with the Common
 Lisp type system. A mechanism for type coercion is also included,
@@ -213,9 +216,9 @@
 facilities will automatically adapt to use whatever toolkit is
 available and appropriate for the host environment. In addition,
 portable Lisp-based implementations of the abstract gadget pane
-protocols are provided.\footnote{McCLIM does not support look and feel
-  adaptiveness at the moment except for the experimental port for Mac
-  OS X. Hence, McCLIM mostly uses this portable Lisp-based
+protocols are provided.\footnote{\mcclim{} does not support look and feel
+  adaptiveness at the moment except for the experimental beagle backend for Mac
+  OS X's Cocoa platform. Hence, \mcclim{} mostly uses this portable Lisp-based
   implementation.}
 
 \paragraph*{Application Building} \CLIM{} provides a set of tools for
@@ -237,13 +240,14 @@
 stream, the \CLIM{} programmer can also attach the code that generated
 the content to the content itself. Whenever necessary, the application
 programmer can ask an output stream to update itself. \CLIM{} will
-query all code generators and in case, replace obsolete content.
+query all drawn elements for obsolescence, and if necessary, rerun the
+code to produce fresh output.
 
 \noindent\hrulefill
 
-\noindent These are a lot of facilities to explore. The most
-systematically way -- exploring from the most low-level to the most
-high-level -- would also be the most longsome. Therefore, we start
+\noindent This is a large number of facilities to explore. The most
+systematic way -- progressing from the lowest-level to the highest
+-- would also be the lengthiest. Therefore, we start
 with showing several facilities in action with the most fundamental
 example in the realm of programming: Hello World.
 
@@ -318,13 +322,12 @@
 
 The one and only superclass of \class{hello-world-pane} is
 \class{clim-stream-pane}\footnote{See Section 29.4 ``CLIM Stream
-  Panes'' in \cite{clim-spec}.}. As there are no additional slot, an
-experience CLOS user might have correctly guessed that we will use
-\class{hello-world-pane} solely for method specialization.
-
-But before we do that, let us have a look what we have actually
+  Panes'' in \cite{clim-spec}.}. As there are no additional slots, an
+experienced \CLOS{} user might guess that we will use
+\class{hello-world-pane} solely for method specialization.  Before doing so,
+let us have a look what we have actually
 inherited from \class{clim-stream-pane}\footnote{Internal classes
-  removed from Listing}:
+  removed from listing.}:
 
 \pagebreak % formathack
 \lstset{style=inlinestyle}
@@ -394,13 +397,13 @@
 To \CLIM{}, geometry means \concept{regions}. A region is either bound
 or unbound and has a dimensionality of either zero, one or two. That
 corresponds to a point, a path or an area respectively. Regions can be
-compared (region predicate protocol\footnote{\CLIM{} relays heavily on
-  CLOS. In CLOS, the term \concept{protocol} means a set of generic
+compared (region predicate protocol\footnote{\CLIM{} relies heavily on
+  \CLOS{}. In \CLOS{}, the term \concept{protocol} means a set of generic
   functions that together form a coherent interface. A protocol
-  specification does not only include the syntactic details of the
+  specification not only includes the syntactic details of the
   function names and the number of function arguments, but also the
-  functions purpose and the semantic of the return values (and/or side
-  effects) must be given in a textual specification.}) and composed
+  functions' purpose and the semantics of the return values and/or side
+  effects.}) and composed
 (region composition protocol).
 
 Every bounded region has a \concept{bounding rectangle}. It is the
@@ -422,14 +425,14 @@
 \subsection{The Windowing Substrate} 
 
 \CLIM{} does not directly talk to the window system. Instead, \CLIM{}
-is layered on top of a windowing substrate\footnote{former Silica}.
+is layered on top of a windowing substrate.\footnote{formerly known as Silica.}
 This substrate is a middleware between \CLIM{} on one side and the
 host window system on the other.  This middleware layer provides a
 portable windowing model that insulates higher levels of \CLIM{} and
 \CLIM{} programmers from the details of the host window system. From
 the perspective of a \CLIM{} programmer, talking to the window system
 is equal to talking to this abstraction layer. The implementation
-details are hidden in \concept{backends}, like in McCLIM the CLX
+details are hidden in \concept{backends}, like in \mcclim{} the CLX
 backend, which hides X11 details, or the beagle backend, which hides
 details for Mac OS X's toolkit. These backends will use the services
 of a host window system to provide efficient windowing, input and
@@ -440,7 +443,7 @@
 blocks:
 \begin{itemize}
 \item Windows like those in X, Mac OS X and Microsoft Windows.
-\item Gadgets typical of toolkit layers, such as GTK, QT or Mac OS X's
+\item Gadgets typical of toolkit layers, such as Gtk+, QT or Mac OS X's
   toolkit. The backend provides a frame manager which takes care of
   mapping the abstract gadget types found in \CLIM{} to appropriate
   gadget with a native look and feel.
@@ -480,7 +483,7 @@
 children. A sheet can be adopted by a parent sheet and disowned later.
 A sheet is grafted when it is connected to a \concept{graft} either
 directly or through it's ancestors. A graft is a special kind of sheet
-that stands in for a host window, typically a root window (i.e. screen
+that stands in for a host window, typically a root window (i.e.{} screen
 level). A sheet is attached to a particular host window system by
 making it a child of an associated graft. A host window will be
 allocated for that sheet; the sheet will then appear to be a child of
@@ -545,12 +548,12 @@
 sheet.
 % \footnote{Notice that the \CLIM{} specification \cite{clim-spec}
 %   specifies draw-text, draw-line, draw-rectangle, etc. as functions
-%   that operate on mediums. McCLIM names these functions
+%   that operate on mediums. \mcclim{} names these functions
 %   medium-draw-text, medium-draw-line, medium-draw-rectangle, and so
-%   on. The functions that are available in McCLIM without the
+%   on. The functions that are available in \mcclim{} without the
 %   ``medium-'' prefix operate on sheets. These are trampoline
 %   functions that call the appropriate medium-prefixed function on
-%   the sheet's medium. According to the McCLIM authors, this is done
+%   the sheet's medium. According to the \mcclim{} authors, this is done
 %   for optimization.}
 
 The graphic output capabilities of sheets range from simple line style
@@ -563,9 +566,9 @@
 
 \CLIM{} lives in idealized world in terms of graphics operations. A
 \CLIM{} programmer can use an infinitely long and wide drawing pane
-with an arbitrary precise resolution and continuously variable amount
-of opacity. As rendering devices with these properties are rare these
-days, we need to render the idealized graphic description to a device
+with an arbitrarily precise resolution and continuously variable 
+opacity. As rendering devices with these properties are rare,
+we need to render the idealized graphic description to a device
 with finite size and a fixed drawing precision. The rendering rules
 are specified in Section 12.4 ``Rendering Conventions for Geometric
 Shapes''of \cite{clim-spec}.
@@ -596,7 +599,7 @@
 To build a user interface, an application programmer defines one or
 more frames classes. These frame classes define a number of frame
 properties including application specific state and a hierarchy of
-panes (i.e. user interface gadgets and regions for interacting with
+panes (i.e.{} user interface gadgets and regions, for interacting with
 the users). Frame classes also provide hooks for customizing
 application behavior during various portions of the frame protocol.
 For example, an \keyword{:after} method on generic functions in the
@@ -616,13 +619,13 @@
 asynchronously handling confirmation or cancel button clicks.  For
 instance, the programmer requests a string from the user and the user
 is presented with a prompt, an editable text field, and two buttons
-for confirmation and canceling. Only after the user hit the
-confirmation button, the string requesting function returns and the
+for confirmation and canceling. Only after the user hits the
+confirmation button will the string requesting function return; the
 programmer can directly use the function's return value which is the
-user provided string. A cancel button click is handled via throwing an
-abort tag.
+string provided by the user. Clicking the cancel button is dealt with by throwing to an
+\code{abort} tag.
 
-From the callers perspective, an attempt to separate application
+From the caller's perspective, an attempt to separate application
 frames and dialogs could be: a dialog window itself is side-effect
 free with respect to the application state and therefore the whole
 sense of calling a dialog creation routine must arise from the values
@@ -648,7 +651,7 @@
 additional information for (or before) an operation. When the user
 selects the ``Search'' command, he is queried for a search string in
 an additional dialog window; probably offering other search options
-like case insensitive search or backwards search. This is done in a
+like case-insensitive search or backwards search. This is done in a
 synchronous manner, blocking until the requested input is made
 available by the user.
 
@@ -669,9 +672,9 @@
 An application frame is an interface that provides the user with a
 variety of commands to choose as his next step. For instance, the user
 may choose from commands like Open, Save, Search, or Quit. The frame
-is a long-living GUI object compared to dialogs and there is no linear
+is a long-living GUI object compared to dialogs, and there is no linear
 execution path as there is in after a dialog as the user is free to
-select any commands he likes as next step.
+select any commands he likes as his next action.
 
 Hence, the synchronous programming pattern for dialogs is more
 convenient because after dialog confirmations there is a predetermined
@@ -701,7 +704,7 @@
 top-level pane in \macro{define-application-frame}. This pane is
 usually a layout pane that contains more gadget and/or layout panes as
 its children. With the help of layout panes, a pane hierarchy can be
-constructed. The top-level pane (and the whole hierarchy when its a
+constructed. The top-level pane (and the whole hierarchy when it is a
 layout pane) is created when the application frame is adopted by a
 frame manager and made visible to the user. The programmer can compose
 an interface consisting of pre-defined gadget panes, layout panes, or
@@ -717,27 +720,27 @@
 augmenting the class with an active part. For instance, a button-pane
 actively draws its own button representation on its allotted screen
 area and a click on the correct button area triggers a callback for
-the button. A composite pane lays out its children elements and
-request them to draw themselves onto specific screen regions.
+the button. A composite pane lays out its child elements and
+requests them to draw themselves onto specific screen regions.
 
 \CLIM{} comes with a set of predefined gadget panes. They consist of
 push-button, toggle-button, slider, radio-box, text-field, text-editor
 panes ready for use by the \CLIM{} application programmer. These
 gadgets might be remapped to native system gadgets by the frame
 manager, so a native look and feel is possible.\footnote{Only possible
-  in McCLIM with the experimental beagle backend for Mac OS X.}
+  in \mcclim{} with the experimental beagle backend for Mac OS X.}
 
 Each gadget pane class is associated with a set of generic functions
-that as callbacks in traditional toolkits. For example, a pushbutton
+that act as callbacks do in traditional toolkits. For example, a pushbutton
 has an ``activate'' callback method which is invoked when its button
 is pressed. For this particular callback, a method named
-\method{activate-callback} is invoked per default and a \CLIM{}
-programmer can provide a specialized method to implementation
-application specific behavior for a subclassed button-pane. But except
+\method{activate-callback} is invoked by default, and a \CLIM{}
+programmer can provide a specialized method to implement
+application-specific behavior for a subclassed button-pane. But except
 in the case where the programmer needs a lot of buttons with related
 behavior, creating a subclass for changing a single specific callback
 is not economical. Hence upon gadget creation, the programmer can
-specify an alternative callback method for all callback available. By
+specify an alternative callback method for all callbacks available. By
 providing the \keyword{:activate-callback} initarg, the programmer can
 change the callback to any regular or generic function. By convention,
 all callbacks can be changed by providing an initarg keyword equal to
@@ -810,14 +813,14 @@
 separately. This example illustrates the use of gadget panes provided
 by \CLIM{}. In the code in Figure \ref{fig-color-editor}, we define an
 application frame using \method{define-application-frame}. As said
-before, the syntax of this macro is similar to \class{defclass}. It
+before, the syntax of this macro is similar to that of \class{defclass}. It
 defines a new frame class which automatically inherits from the class
 \class{frame} which provides most of the functionality for handling
 frames.
 
 One requirement must be fulfilled by all frame definitions: code to
 generate a pane hierarchy must be supplied. The \keyword{:pane} option
-is the simplest way to supply this code. \class{hello frame}
+is the simplest way to supply this code.  The \class{hello-world} frame
 constructs a hierarchy with only one application pane via
 \method{make-pane}. The pane hierarchy of color editor is more
 interesting.
@@ -896,7 +899,7 @@
 whether the mouse button is held down during dragging, or whether the
 mouse button is pressed once to start and again to stop dragging.
 
-We use the gadget id to distinguish between the red, green and blue
+We use the gadget ID to distinguish between the red, green and blue
 slider in the callback code. We could use three different callback
 functions here, but such callbacks would have much more similarities
 than differences, thus we do not do that here. Instead, we distinguish
@@ -940,15 +943,15 @@
 
 \subsection{A simple drawing application}
 
-Next in our show case, we have a simple drawing application that draws
+We move on to a simple drawing application that draws
 lines and inserts text interactively. Our simple drawing program
 defines commands for various drawing operations and binds specific
 input events to these commands.
 
 The application frame is defined in
 \figurename~\ref{fig-draw-defapp}. A different approach is used to
-generate the pane hierarchy. Instead of mixing the layout and pane
-information, we used the \keyword{:panes} keyword to list all panes
+generate the pane hierarchy: instead of mixing the layout and pane
+information, we use the \keyword{:panes} keyword to list all panes
 that should be available in frame layouts. The \keyword{:layouts}
 keyword combines them into several layouts. It is possible to define
 multiple layouts with this option. We define two simple layouts,
@@ -973,16 +976,16 @@
 class. Passing \constant{t} to this option (its default) generates a
 command definer named
 \macro{define-\texttt{<}frame-name\texttt{>}-command}. We can use the
-command-defining macro as convenience macro for
-\method{define-command} which is used to define frame commands. We
-will see them in action before long. \keyword{:top-level} specifies a
+command-defining macro as a convenience macro for
+\method{define-command} which is used to define frame commands, and 
+will see it in action before long. \keyword{:top-level} specifies a
 special form that is used as top level command loop. The top level is
 responsible for dequeuing and executing commands that have been
 invoked by the user. This loop is to a application frame what the REPL
 is to a terminal.
 
 This is the first example that does not use \class{clim-stream-pane}
-(or one of its descendant) as pane class.\footnote{When using McCLIM,
+(or one of its subclasses) as a pane class.\footnote{When using \mcclim{},
 we have to do this as there are bugs in the behavior of
 \class{clim-stream-pane} that have not been fixed yet.} Instead, we
 compose our own drawing pane using
@@ -994,21 +997,21 @@
 handling all requests belonging to the sheet and pane protocols in a
 standard manner. The last class is a mixin to tag the pane as
 permanently visible on screen during its instances' lifetime. Most
-static user interfaces use this mixin. Notice that McCLIM is sensible
-to the order of the superclasses.\footnote{All stream class like
+static user interfaces use this mixin. Note that \mcclim{} is sensitive
+to the order of the superclasses.\footnote{All stream classes like
 \class{standard-extended-input-stream} must be listed before
-\class{basic-pane}. Otherwise, there is no stream handling facilities
+\class{basic-pane}. Otherwise, there are no stream handling facilities
 available.}
 
 For \class{draw-pane}, the \method{handle-repaint} method shown in
-\figurename~\ref{fig-draw-handlerepaint} is straight forward. It
+\figurename~\ref{fig-draw-handlerepaint} is straightforward. It
 delegates background filling to the next less specific method and then
 iterates through the lines and strings painting them. Here, we
 implicitly defined the format of the \code{lines} slot and the
 \code{strings} slot of the application frame class. The elements of
 the list stored in \code{lines} are pairs of points, namely the start
 and end point for a line. In \code{strings}, we store the text's
-position as the first element of a cons and the text as its cdr.
+position as the \code{car} of a cons and the text as its \code{cdr}.
 
 % \class{draw-frame} uses two options in
 % \macro{define-application-frame} that we have not encountered
@@ -1026,9 +1029,9 @@
 draw pane. After every command, we update the drawing pane via the
 auxiliary method \method{update-draw-pane}.\footnote{An experienced
 \CLIM{} programmer would define a display-function for
-\class{draw-pane}. These function is run whenever a command was
-executed causing the display pane to be updated with any changes. But
-we will save this technique for later examples.}
+\class{draw-pane}. This function is run after a command is
+executed, and causes the display pane to be updated with any changes. We 
+will save this technique for later examples.}
 
 At this point, we can actually use the application; although not very
 conveniently. The interactor pane can be used to invoke one of three
@@ -1128,10 +1131,10 @@
 % event-handling thread.
 % 
 
-You may notice that there are issue with redrawing with this example
-in McCLIM. Unfortunately, this has not been fixed before the release
+You may notice that there are issues with redrawing with this example
+in \mcclim{}. Unfortunately, this has not been fixed before the release
 of this article.
-
+%\footnote{}?
 
 \section{High Level Facilities} 
 
@@ -1170,7 +1173,7 @@
 \paragraph*{Output Formatting} \CLIM{} provides a convenient table and
 graph formatting facility, which is built on top of the output
 recording facility. The key to these formatting tools (as opposed to,
-say, \code{format}'s X directive) is that they dynamically compute the
+say, \code{format}'s \code{~T} directive) is that they dynamically compute the
 formatting parameters based on the actual size of the
 application-generated output.
 
@@ -1195,7 +1198,7 @@
 Any attempt to fix this function to produce tabular output by building
 in a certain fixed spacing between the package name and symbol count
 will either get caught by an unexpectedly long package name, or will
-have to reserve way to much space for the typical case. In \CLIM{}, we
+have to reserve way too much space for the typical case. In \CLIM{}, we
 can use the code in Figure \ref{fig-formatting} to produce a neatly
 formatted table for any set of package names.
 \begin{figure*}
@@ -1230,7 +1233,7 @@
 the semantics can be recovered from the string. Thus the power of the
 various textual cut-and-paste mechanisms supported by contemporary
 computer systems. However, it is possible to improve upon the utility
-of this lowest common denominator facility (i.e. squeezing everything
+of this lowest common denominator facility (i.e.{} squeezing everything
 through its printed representation) by remembering the semantics of
 the output as well as its appearance. This is the idea behind
 presentations.
@@ -1258,10 +1261,10 @@
 types, which are arranged in a super-type/subtype lattice like the CL
 types. In fact, the presentation type hierarchy is an extension of the
 CL type hierarchy. The reason that this extended type system is needed
-is that the CL type system is overloaded from the UI perspective. For
+is that the CL type system is insufficient from the UI perspective. For
 example, the integer 72 might represent a heart rate in one
 application and a Fahrenheit temperature in another, but it will
-always just be an integer to Lisp.
+always be just an integer to Lisp.
 
 The application programmer can define the UI entities of the
 application by defining presentation types, thus extending the
@@ -1270,7 +1273,7 @@
 place, including output appearance and input syntax. As an example,
 \CLIM{} defines a pathname presentation type that defines how a
 pathname is displayed and how one is input. The pathname input side
-provides pathname completion and possibilities-display features. By
+provides pathname completion and display of possibilities. By
 defining this behavior in one place and using it in all applications
 that need to display or read pathnames, \CLIM{} helps build consistent
 user interfaces.
@@ -1284,9 +1287,9 @@
 
 \begin{lstlisting}
 (with-output-as-presentation 
-       (:object path
-        :type 'pathname 
-        :stream s) 
+    (:object path
+     :type 'pathname 
+     :stream s) 
   (draw-rectangle* s 0 0 30 30))
 \end{lstlisting}
 
@@ -1358,17 +1361,17 @@
 \caption{File Browser}\label{fig-file-browser}
 \end{figure*}
 
-The \class{dirlist-frame} application is a very simple-minded file
+The \class{dirlist-frame} application is a very simple file
 system browser using presentation types.  It defines two panes, an
 output pane to display directory contents and an input pane to handle
 user typein.  For the output pane, the application defines a display
 function. \code{dirlist-display-files} works in conjunction with the
-top level command loop. Per default, the command loop calls all
+top level command loop. By default, the command loop calls all
 display functions after a command was processed to make all changes in
 the application's data structures visible that the command execution
 might have caused. When all display functions have updated their
 panes, the command loop displays a prompt in the
-interactor\footnote{Might be omitted when there is no interactor pane}
+interactor\footnote{Omitted when there is no interactor pane.}
 and waits for the next command.
 
 The \method{dirlist-display-files} display function iterates over the
@@ -1414,8 +1417,8 @@
 translator has to return a list of arguments that are handed to the
 command \code{com-edit-directory}. But we do not need to any
 conversion of the supplied object, as it is already a pathname. Thus,
-the received object is wrapped in a list and handed back to the caller
-which will call \code{com-edit-directory} with the supplied objects.
+the object is wrapped in a list and returned to the caller
+which will apply \code{com-edit-directory} to the list.
 
 A simple trick is used to dispatch an initial command to the
 application frame. An after-method is provided for
@@ -1463,17 +1466,16 @@
 and a parser function for the type \code{weekday}. As is the case with
 most presentation types, the printer and parser are duals. That is,
 the printer, when given an object to print, produces output that the
-parser can interpret to arrive back at the original object. Not in
-every case the parser in \code{accept} is needed to return an object
-of the requested type, and for simplicity the programmer might choose
-not to provide a parser at all.
+parser can interpret to arrive back at the original object.
+\code{accept} does not need a parser in every case, and for simplicity
+the programmer might choose not to provide a parser at all.
 
 We took the easy way out with our parser. \CLIM{} provides a
 completion facility and instead of reading the day name of the stream
 and parsing it into an integer, we provided an exhaustive set of input
 to object mappings. The \macro{completing-from-suggestions} macro
 collects all suggestions made by the parser via
-\code{suggest}. \code{suggest} is takes an input and object as
+\code{suggest}. \code{suggest} takes an input and object as
 suggestion. In our case, day name taken from \variable{*days*} is the
 input and the number of the week \variable{i} is the object. \CLIM{}
 will match the input given by the user with the suggestions and in
@@ -1513,7 +1515,7 @@
 precisely, a presentation-to-command translator is defined that is
 equal in functionality to the one we have seen in the file-browser
 example. Whenever a presentation of the type \code{pathname} is
-selected (e.g. with pointer clicks) in a \class{command} input
+selected (e.g.{} with pointer clicks) in a \class{command} input
 context, it is translated into a command invocation of ``Select
 Weekday''.
 
@@ -1605,27 +1607,28 @@
 
 \section{Conclusion}
 
-The series of examples presented in this article illustrate the broad
+The series of examples presented in this article illustrates the broad
 range of functionality provided by \CLIM{}. The later examples,
 especially, demonstrate that complex user interfaces can be built
-economically and modularly using \CLIM{}. Many of the higher level
+economically and in a modular fashion using \CLIM{}. Many of the higher level
 facilities make it possible to separate the issues involved in
 designing an application's user interface from the functionality of
 the application.
 
-On the other hand, many of these higher level facilities may not be
-appropriate for all users. \CLIM{}'s lower level facilities and clean
-modularization of the higher level facilities provide these users with
+On the other hand, these higher level facilities are not
+appropriate for all programmers. \CLIM{}'s lower level facilities and clean
+modularization of the higher level facilities provide these programmers with
 portable platform and a framework for implementing their own user
-interface toolkits and frameworks. In addition, \CLIM{}'s use of CLOS
+interface toolkits and frameworks. In addition, \CLIM{}'s use of \CLOS{}
 to define explicit, documented protocols provides application
 programmers with the opportunity to customize \CLIM{} and support
 interfaces not anticipated by the \CLIM{} designers.
 
-A free \CLIM{} implementation is available as McCLIM. McCLIM only
-works on X windows at the moment. An experimental port to Mac OS X
-called Beagle is in progress. It can be found on
-http://common-lisp.net/project/mcclim/.
+A free \CLIM{} implementation is available as \mcclim{}, found at
+\url{http://common-lisp.net/project/mcclim/}. In addition to the
+caveats in this document, note that \mcclim{} only works with an X
+windows backend as of January 2006.  An experimental port called
+beagle to the native toolkit of Mac OS X is in progress.
 
 \section*{Acknowledgments}
 
@@ -1638,9 +1641,9 @@
 Mark Son-Bell and Jon L. White have help us improve this paper.
 
 \paragraph*{2006 update} Clemens Fruhwirth thanks the developers for
-McCLIM for producing a free \CLIM{} implementation, and especially
+\mcclim{} for producing a free \CLIM{} implementation, and especially
 Robert Strandh for answering so many questions in conjunction with
-McCLIM.
+\mcclim{}.
 
 \bibliographystyle{alpha}
 \bibliography{guided-tour}
