kpsewhich now expects "-var-value" instead of "-var".
[ibg.git] / chapters / 06.rst
index 603663d440432167be10a0b434df032c3ccf13b0..e242057f9fc5a16fc50e8fe792fb91e7bd1e0b2e 100644 (file)
@@ -26,7 +26,11 @@ Initial setup
 =============
 
 Our starting point is much the same as last time.  Here's a basic
 =============
 
 Our starting point is much the same as last time.  Here's a basic
-``Tell.inf``::
+``Tell.inf``:
+
+.. include:: /config/typethis.rst
+
+::
 
    !% -SD
    !===========================================================================
 
    !% -SD
    !===========================================================================
@@ -155,9 +159,9 @@ pieces:
 
      Why not do that with the player?  Because the object which represents
      the player is defined by the library (rather than as part of our
 
      Why not do that with the player?  Because the object which represents
      the player is defined by the library (rather than as part of our
-     game), and actually has an internal ID of ``selfobj``; :var:`player`
-     is a variable whose value is that identifier.  Rather than worry all
-     about this, it's easier to use the ``move`` statements.
+     game), and actually has an internal ID of :obj:`selfobj`;
+     :var:`player` is a variable whose value is that identifier.  Rather
+     than worry all about this, it's easier to use the ``move`` statements.
 
   There's one other task associated with the quiver; it's an article of
   clothing which Wilhelm is "wearing", a state denoted by the attribute
 
   There's one other task associated with the quiver; it's an article of
   clothing which Wilhelm is "wearing", a state denoted by the attribute
@@ -172,6 +176,10 @@ pieces:
   quiver ~worn`` -- read that as "give the quiver not-worn"; Inform often
   uses ``~`` to mean "not".)
 
   quiver ~worn`` -- read that as "give the quiver not-worn"; Inform often
   uses ``~`` to mean "not".)
 
+.. Generated by autoindex
+.. index::
+   pair: description; library property
+
 * If the player types EXAMINE ME, the interpreter displays the
   :prop:`description` property of the :var:`player` object.  The default
   value is "As good-looking as ever", a bit of a cliché in the world of
 * If the player types EXAMINE ME, the interpreter displays the
   :prop:`description` property of the :var:`player` object.  The default
   value is "As good-looking as ever", a bit of a cliché in the world of
@@ -313,7 +321,11 @@ In fact, for any object both the block of properties and the block of
 attributes are optional and can be omitted if there's nothing to be
 specified.  Now that the :attr:`light` attribute is being provided
 automatically and there aren't any other attributes to set, the word
 attributes are optional and can be omitted if there's nothing to be
 specified.  Now that the :attr:`light` attribute is being provided
 automatically and there aren't any other attributes to set, the word
-``has`` can be left out.  Here's the class again::
+``has`` can be left out.  Here's the class again:
+
+.. include:: /config/typethis.rst
+
+::
 
    Class  Room
      has  light;
 
    Class  Room
      has  light;
@@ -344,7 +356,11 @@ We use the ``Room`` class in "William Tell", and a few other classes
 besides.  Here's a ``Prop`` class (that's "Prop" in the sense of a
 theatrical property rather than a supportive device), useful for scenic
 items whose only role is to sit waiting in the background on the off-chance
 besides.  Here's a ``Prop`` class (that's "Prop" in the sense of a
 theatrical property rather than a supportive device), useful for scenic
 items whose only role is to sit waiting in the background on the off-chance
-that the player might think to EXAMINE them::
+that the player might think to EXAMINE them:
+
+.. include:: /config/typethis.rst
+
+::
 
    Class    Prop
      with   before [;
 
    Class    Prop
      with   before [;
@@ -366,16 +382,22 @@ the first :prop:`before` we met looked like this::
        return true;
    ],
 
        return true;
    ],
 
-The role of that original :prop:`before` was to intercept ``Listen``
+.. Generated by autoindex
+.. index::
+   pair: Examine; library action
+   pair: Listen; library action
+
+The role of that original :prop:`before` was to intercept :act:`Listen`
 actions, while leaving all others well alone.  The role of the
 :prop:`before` in the ``Prop`` class is broader: to intercept (a)
 actions, while leaving all others well alone.  The role of the
 :prop:`before` in the ``Prop`` class is broader: to intercept (a)
-``Examine`` actions, and (b) all the rest.  If the action is ``Examine``,
-then the ``return false`` statement means that the action carries on.  If
-the action is ``default`` -- none of those explicitly listed, which in this
-instance means *every* action apart from ``Examine`` -- then the
-``print_ret`` statement is executed, after which the interpreter does
-nothing further.  So, a ``Prop`` object can be EXAMINEd, but any other
-action addressed to it results in a "no need to worry" message.
+:act:`Examine` actions, and (b) all the rest.  If the action is
+:act:`Examine`, then the ``return false`` statement means that the action
+carries on.  If the action is ``default`` -- none of those explicitly
+listed, which in this instance means *every* action apart from
+:act:`Examine` -- then the ``print_ret`` statement is executed, after which
+the interpreter does nothing further.  So, a ``Prop`` object can be
+EXAMINEd, but any other action addressed to it results in a "no need to
+worry" message.
 
 That message is also more involved than anything we've so far displayed.
 The statement which produces it is::
 
 That message is also more involved than anything we've so far displayed.
 The statement which produces it is::
@@ -410,6 +432,10 @@ The interesting things that this statement demonstrates are:
   display the following object's internal ID, is called a :term:`print
   rule`.
 
   display the following object's internal ID, is called a :term:`print
   rule`.
 
+.. Generated by autoindex
+.. index::
+   pair: self; library variable
+
 * There's a library variable :var:`self` which always contains the internal
   ID of the current object, and is really convenient when using a
   ``Class``.  By using this variable in our ``print_ret`` statement, we
 * There's a library variable :var:`self` which always contains the internal
   ID of the current object, and is really convenient when using a
   ``Class``.  By using this variable in our ``print_ret`` statement, we
@@ -436,13 +462,22 @@ would be a waste of time.
 A class for furniture
 ---------------------
 
 A class for furniture
 ---------------------
 
+.. Generated by autoindex
+.. index::
+   single: NPC
+   pair: static; library attribute
+
 The last class for now -- we'll talk about the ``Arrow`` and ``NPC``
 classes in the next chapter -- is for furniture-like objects.  If you label
 an object with the :attr:`static` attribute, an attempt to TAKE it results
 in "That's fixed in place" -- acceptable in the case of Heidi's branch
 object (which is indeed supposed to be part of the tree), less so for items
 which are simply large and heavy.  This ``Furniture`` class might sometimes
 The last class for now -- we'll talk about the ``Arrow`` and ``NPC``
 classes in the next chapter -- is for furniture-like objects.  If you label
 an object with the :attr:`static` attribute, an attempt to TAKE it results
 in "That's fixed in place" -- acceptable in the case of Heidi's branch
 object (which is indeed supposed to be part of the tree), less so for items
 which are simply large and heavy.  This ``Furniture`` class might sometimes
-be more appropriate::
+be more appropriate:
+
+.. include:: /config/typethis.rst
+
+::
 
    Class    Furniture
      with   before [;
 
    Class    Furniture
      with   before [;
@@ -464,10 +499,14 @@ intercepting four actions; we *could* have written the property like this::
        PushDir: print_ret (The) self, " is too heavy for that.";
    ],
 
        PushDir: print_ret (The) self, " is too heavy for that.";
    ],
 
+.. Generated by autoindex
+.. index::
+   pair: PushDir; library action
+
 but since we're giving exactly the same response each time, it's better to
 but since we're giving exactly the same response each time, it's better to
-put all of those actions into one list, separated by commas.  ``PushDir``,
-if you were wondering, is the action triggered by a command like PUSH THE
-TABLE NORTH.
+put all of those actions into one list, separated by commas.
+:act:`PushDir`, if you were wondering, is the action triggered by a command
+like PUSH THE TABLE NORTH.
 
 Incidentally, another bonus of defining classes like these is that you can
 probably reuse them in your next game.
 
 Incidentally, another bonus of defining classes like these is that you can
 probably reuse them in your next game.