X-Git-Url: https://jxself.org/git/?a=blobdiff_plain;f=chapters%2F11.rst;h=ef710042f394ad635dba527b6ba76756de47d448;hb=f0b3c1de40eb2b2f228e43e99bf0535b1c2ea5da;hp=26019719229b0c7bba45553a2e8856df1b3fb983;hpb=7042413e580a0709340a1bd04130d7a277b2c882;p=ibg.git

diff --git a/chapters/11.rst b/chapters/11.rst
index 2601971..ef71004 100644
--- a/chapters/11.rst
+++ b/chapters/11.rst
@@ -21,6 +21,8 @@ with lunchtime customers. We'll try to conjure up some appropriate
 images, but the main focus of the room isn't the decor: it's the door 
 leading to the toilet -- and, perhaps, privacy?
 
+.. _homely-atmos:
+
 A homely atmosphere
 ===================
 
@@ -41,7 +43,7 @@ the door seems to be locked.
 
 We define the café room in simple form:
 
-.. code-block:: inform6
+.. code-block:: inform
 
   Room    cafe "Inside Benny's cafe"
     with  description
@@ -58,7 +60,7 @@ define the door object which lies between the café and the toilet.
 
 We've mentioned a counter:
 
-.. code-block:: inform6
+.. code-block:: inform
 
   Appliance counter "counter" cafe
     with name 'counter' 'bar',
@@ -93,22 +95,23 @@ let the action continue, ``true`` to prevent it.
   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 **fake action**.
+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 "The 
-  player's possessions" on page 83, 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):
+  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):
 
-  .. code-block:: inform6
+  .. code-block:: inform
 
     before [;
       Drop,Give:
@@ -128,7 +131,7 @@ way for the player to accomplish this.
 We've also mentioned some customers. These are treated as NPCs, reacting 
 to our hero’s performance.
 
-.. code-block:: inform6
+.. code-block:: inform
 
   Object  customers "customers" cafe
     with  name 'customers' 'people' 'customer' 'men' 'women',
@@ -248,7 +251,7 @@ customers are -- so we need to make certain that the daemon does
 something interesting only while the player stays in the right place 
 (and hasn’t wandered, say, back into the toilet):
 
-.. code-block:: inform6
+.. code-block:: inform
 
   if (location ~= cafe) return;
 
@@ -262,7 +265,7 @@ control the sequence of customers' remarks. When the Captain enters the
 café room from the toilet for the first time, the value of the property 
 should be zero, so the statement block under the test:
 
-.. code-block:: inform6
+.. code-block:: inform
 
   if (self.number_of_comments == 0) {
       self.number_of_comments = 1;
@@ -280,7 +283,7 @@ daemon will continue normally to the next line.
 We want the customers to indulge in witticisms once they see the 
 costumed Captain, but not on a completely predictable basis.
 
-.. code-block:: inform6
+.. code-block:: inform
 
   if (random(2) == 1) ...
 
@@ -311,7 +314,7 @@ the café in their Captain’s outfit, they’ll be coming from the toilet.
 As a consequence of all this, we add an ``after`` property to the café 
 room object:
 
-.. code-block:: inform6
+.. code-block:: inform
 
   Room   cafe "Inside Benny's cafe"
          ...
@@ -338,7 +341,7 @@ the player just came from the toilet, so we use an ``after`` property.
 
 The first line:
 
-.. code-block:: inform6
+.. code-block:: inform
 
   if (noun ~= s_obj) return false;
 
@@ -364,7 +367,7 @@ A door to adore
 Door objects require some specific properties and attributes. Let's 
 first code a simple door:
 
-.. code-block:: inform6
+.. code-block:: inform
 
   Object  toilet_door "toilet door" cafe
     name name 'red' 'toilet' 'door',
@@ -422,7 +425,7 @@ and its possible states affect both sides. However, the coding gets a
 little bit complicated and you''ll have to define routines for most 
 properties:
 
-.. code-block:: inform6
+.. code-block:: inform
 
   Object  toilet_door "toilet door"
     with  name 'red' 'toilet' 'door',
@@ -462,7 +465,7 @@ the cafe", depending on the side we are facing. For this, a ``short_name
 property`` is the thing. We have already talked about the external name 
 defined as part of an object's header information:
 
-.. code-block:: inform6
+.. code-block:: inform
 
   Object  toilet_door "toilet door"
 
@@ -470,7 +473,7 @@ That ``toilet door`` will be the name displayed by the game at run-time
 to refer to the door. With identical effect, this could also have been 
 coded thus:
 
-.. code-block:: inform6
+.. code-block:: inform
 
   Object  toilet_door
     with  short_name "toilet door",
@@ -481,7 +484,7 @@ retain the same external name throughout the game -- and the header
 information method is perfect in that case -- but if it needs to change, 
 it's easy to write a routine as the value of ``short_name``:
 
-.. code-block:: inform6
+.. code-block:: inform
 
   Object  toilet_door
     with  name 'red' 'toilet' 'door'
@@ -502,13 +505,13 @@ adjectives -- perhaps a shining/flickering/fading/useless lantern.
 
 .. note::
 
-  what's displayed if there isn't an external name in an object's 
-  header? If you've read the section "Compile-as-you-go" on page 233, 
-  you'll recall that the interpreter simply uses the internal 
-  identifier within parentheses; that is, with no external name and no 
-  ``short_name`` property, we might see:
+  what's displayed if there isn't an external name in an object's header?
+  If you've read the section :ref:`compile-as-you-go`, you'll recall that
+  the interpreter simply uses the internal identifier within parentheses;
+  that is, with no external name and no ``short_name`` property, we might
+  see:
 
-  .. code-block:: inform6
+  .. code-block:: inform
 
     You open the (toilet_door).
 
@@ -517,7 +520,7 @@ adjectives -- perhaps a shining/flickering/fading/useless lantern.
   of our ``print`` statement, and then the standard rules would display 
   the internal ID:
 
-  .. code-block:: inform6
+  .. code-block:: inform
 
     You open the door to the toilet(toilet_door).
 
@@ -544,7 +547,7 @@ If a few lines of code can make the life of the player easier, it's
 worth a shot. Let's provide a few improvements to our toilet door in 
 ``before`` and ``after`` properties:
 
-.. code-block:: inform6
+.. code-block:: inform
 
   before [ ks;
     Open:
@@ -616,7 +619,7 @@ safely restore it afterwards. You’ll remember that a local variable in a
 standalone routine is declared between the routine’s name and the 
 semicolon:
 
-.. code-block:: inform6
+.. code-block:: inform
 
   [ BeenToBefore this_room;
 
@@ -624,7 +627,7 @@ In exactly the same way, a local variable in an embedded routine is
 declared between the ``[`` starting marker of the routine and the 
 semicolon:
 
-.. code-block:: inform6
+.. code-block:: inform
 
   before [ ks;
 
@@ -632,7 +635,7 @@ You can declare up to fifteen variables this way -- just separated by
 spaces -- which are usable only within the embedded routine. When we 
 assign it thus:
 
-.. code-block:: inform6
+.. code-block:: inform
 
   ks = keep_silent;
 
@@ -641,7 +644,7 @@ has (either ``true`` or ``false``; we actually don't care). We then set
 ``keep_silent`` to ``true``, make the desired silent actions, and we 
 assign:
 
-.. code-block:: inform6
+.. code-block:: inform
 
   keep_silent = ks;
 
@@ -660,7 +663,7 @@ So far, we have the player in front of a locked door leading to the
 toilet. A dead end? No, the description mentions a scribbled note on its 
 surface. This one should offer no problem:
 
-.. code-block:: inform6
+.. code-block:: inform
 
   Object  "scribbled note" cafe
     with  name 'scribbled' 'note',
@@ -701,7 +704,7 @@ to ask for it, just as the note explains. Although we'll define Benny in
 detail throughout the next chapter, here we present a basic definition, 
 largely so that the key has a parent object.
 
-.. code-block:: inform6
+.. code-block:: inform
 
   Object  benny "Benny"  cafe
     with  name 'benny',
@@ -742,7 +745,7 @@ 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 
 key while it’s in Benny’s pockets, we define a ``before`` property.
 
-.. code-block:: inform6
+.. code-block:: inform
 
   before [;
       if (self in benny)
@@ -752,21 +755,20 @@ key while it’s in Benny’s pockets, we define a ``before`` property.
       "Benny is trusting you to look after that key.";
   ];
 
-All of the ``before`` properties that we've so far created have 
-contained one or more labels specifying the actions which they are to 
-intercept; you'll remember that in "William Tell" we introduced the 
-``default`` action (see "A class for props" on page 74) to mean "any 
-value not already catered for". There's one of those labels here, for 
-the Drop action, but that's preceded by a piece of code that will be 
-executed at the start of *every* action directed at the key. If it’s 
-still in Benny’s possession, we display a polite refusal; if the player 
-has it then we prevent careless disposal; otherwise, the action 
-continues unhindered.
+All of the ``before`` properties that we've so far created have contained
+one or more labels specifying the actions which they are to intercept;
+you'll remember that in "William Tell" we introduced the ``default`` action
+(see :ref:`props-class`) to mean "any value not already catered
+for". There's one of those labels here, for the Drop action, but that's
+preceded by a piece of code that will be executed at the start of *every*
+action directed at the key. If it’s still in Benny’s possession, we display
+a polite refusal; if the player has it then we prevent careless disposal;
+otherwise, the action continues unhindered.
 
-(In fact, the hat-on-a-pole ``Prop`` introduced on page 91 had this 
-all-exclusive ``before`` property:
+(In fact, the hat-on-a-pole ``Prop`` introduced in :ref:`south-side` had
+this all-exclusive ``before`` property:
 
-.. code-block:: inform6
+.. code-block:: inform
 
   before [;
     default:
@@ -791,7 +793,7 @@ choose to examine the café from the outside. While it's unlikely that
 they'll try to examine the toilet room from the outside, it takes very 
 little effort to offer a sensible output just in case:
 
-.. code-block:: inform6
+.. code-block:: inform
 
   Object  outside_of_toilet "toilet" cafe
     with  name 'toilet' 'bath' 'rest' 'room' 'bathroom' 'restroom',