Resolve TODO from chapter 11.

diff --git a/chapters/11.rst b/chapters/11.rst
index 499f75b057b394660b68c7f7bd49629094a02089..a82408e2247d36fa8e7330cc759124b4c30e12b4 100644 (file)
--- a/chapters/11.rst
+++ b/chapters/11.rst
@@ -72,40 +72,34 @@ We've mentioned a counter:
          ],
     has  supporter;
 
-That :prop:`before` property, superficially normal, actually conceals a 
-little surprise. By now you should be entirely comfortable with using an 
-object's :prop:`before` property to intercept an action directed at that 
-object; for example, if the player types HIT COUNTER then the counter's 
-:prop:`before` property is potentially able to intercept the resulting 
-Attack action. However, the command PUT KEY ON COUNTER generates *two* 
-actions. First, a PutOn action is offered to the key (effectively 
-saying, do you want to be placed on top of the counter?); that’s the 
-normal bit. And then the surprise: a Receive action is offered to the 
-counter (effectively saying, are you happy to have the key placed on 
-you?) Both actions have the same opportunity of returning :const:`false` to 
-let the action continue, :const:`true` to prevent it.
-
-.. todo::
-
-  There are a lot of actions here that are rendered in a typewriter font
-  and others that are not.  Should these ones that are not be promoted 
-  to having a typewriter font?
-
-The Receive action is generated by the library in the PutOnSub action
-handler, and also in InsertSub (so a command like PUT BIRD IN NEST sends a
-Receive to the nest object). There’s a matching LetGo, generated by the
-library from commands like TAKE KEY OFF COUNTER and REMOVE BIRD FROM
-NEST. Receive and LetGo are examples of what’s called a :term:`fake
-action`.
+That :prop:`before` property, superficially normal, actually conceals a
+little surprise. By now you should be entirely comfortable with using an
+object's :prop:`before` property to intercept an action directed at that
+object; for example, if the player types HIT COUNTER then the counter's
+:prop:`before` property is potentially able to intercept the resulting
+``Attack`` action. However, the command PUT KEY ON COUNTER generates *two*
+actions. First, a ``PutOn`` action is offered to the key (effectively
+saying, do you want to be placed on top of the counter?); that’s the normal
+bit. And then the surprise: a ``Receive`` action is offered to the counter
+(effectively saying, are you happy to have the key placed on you?) Both
+actions have the same opportunity of returning :const:`false` to let the
+action continue, :const:`true` to prevent it.
+
+The ``Receive`` action is generated by the library in the ``PutOnSub``
+action handler, and also in ``InsertSub`` (so a command like PUT BIRD IN
+NEST sends a Receive to the nest object). There’s a matching ``LetGo``,
+generated by the library from commands like TAKE KEY OFF COUNTER and REMOVE
+BIRD FROM NEST.  ``Receive`` and ``LetGo`` are examples of what’s called a
+:term:`fake action`.
 
 .. note::
 
   In "William Tell" we defined the ``quiver``, way back in
   :ref:`possessions`, as an ``open container``. As things stand, the player
   can put *any* held object, however inappropriate, into it. We could have
-  trapped the Receive action to ensure that arrows are the only acceptable
-  contents (recollect that ``~~``, to be read as "not", turns true into
-  false and vice versa):
+  trapped the ``Receive`` action to ensure that arrows are the only
+  acceptable contents (recollect that ``~~``, to be read as "not", turns
+  true into false and vice versa):
 
   .. code-block:: inform
 
@@ -213,18 +207,17 @@ need the customers to perform tasks for us, so instead we provide a
 simple rejection message, just in case the player tries to order people 
 around.
 
-Which leaves us with the :prop:`daemon` bit. A daemon is a property normally 
-used to perform some timed or repetitive action without the need of the 
-player’s direct interaction; for example, machines which work by 
-themselves, animals that move on their own, or people going about their 
-business. More powerfully, a daemon may take notice of the player’s 
-decisions at a particular moment, allowing for some interactive 
-behaviour; this is, however, an advanced feature that we won't use in 
-this example. A daemon gets a chance of doing something at the end of 
-every turn, typically to (or with) the object to which it’s associated. 
-In our example, the daemon triggers some sneers and nasty comments from 
-the customers once our hero comes out of the toilet dressed in Captain 
-Fate’s costume.
+Which leaves us with the :prop:`daemon` bit. A daemon is a property
+normally used to perform some timed or repetitive action without the need
+of the player’s direct interaction; for example, machines which work by
+themselves, animals that move on their own, or people going about their
+business. More powerfully, a daemon may take notice of the player’s
+decisions at a particular moment, allowing for some interactive behaviour;
+this is, however, an advanced feature that we won't use in this example. A
+daemon gets a chance of doing something at the end of every turn, typically
+to (or with) the object to which it’s associated.  In our example, the
+daemon triggers some sneers and nasty comments from the customers once our
+hero comes out of the toilet dressed in Captain Fate’s costume.
 
 To code a daemon, you need to do three things:
 
@@ -737,7 +730,7 @@ in scope, and enables the player to refer to it without the interpreter
 complaining. Because Benny also has an :attr:`animate` attribute, the 
 interpreter would normally intercept a TAKE KEY action with "That seems 
 to belong to Benny"; however, the same wouldn't apply to other commands 
-like TOUCH KEY and TASTE KEY . So, to prevent any interaction with the 
+like TOUCH KEY and TASTE KEY. So, to prevent any interaction with the 
 key while it’s in Benny’s pockets, we define a :prop:`before` property.
 
 .. code-block:: inform