Revert to original minimal Inform lexer.
[ibg.git] / chapters / 10.rst
index 0accf1862e3c7a73867183a57947f2a3390c6202..1f1d4b20d6d00267a02088d1c5997d9d1f208174 100644 (file)
@@ -65,7 +65,7 @@ Fade up on: a nondescript city street
 The game starts with meek John Covarth walking down the street. We set 
 up the game as usual:
 
-.. code-block:: inform6
+.. code-block:: inform
 
   !% -SD
   !============================================================================
@@ -132,7 +132,7 @@ up the game as usual:
 
 Almost everything is familar, apart from a few details:
 
-.. code-block:: inform6
+.. code-block:: inform
 
   Constant MANUAL_PRONOUNS;
   Constant MAX_SCORE     2;
@@ -166,7 +166,7 @@ we've decided to modestly award one point for each. By the way, the use
 of an equals sign ``=`` is optional with ``Constant``; these two lines 
 have identical effect:
 
-.. code-block:: inform6..
+.. code-block:: inform
 
   Constant ROOM_SCORE    1;
 
@@ -176,7 +176,7 @@ Another difference has to do with a special short-hand method that
 Inform provides for displaying strings of text. Until now, we have shown 
 you:
 
-.. code-block:: inform6
+.. code-block:: inform
 
   print "And now for something completely different...^"; return true;
   ...
@@ -187,7 +187,7 @@ newline character, and return true. As you have seen in the previous
 example games, this happens quite a lot, so there is a yet shorter way 
 of achieving the same result:
 
-.. code-block:: inform6
+.. code-block:: inform
 
   "And now for something completely different...";
 
@@ -204,7 +204,7 @@ statement instead.
 You'll notice that -- unusually for a room -- our ``street`` object has 
 a ``name`` property:
 
-.. code-block:: inform6
+.. code-block:: inform
 
   Room    street "On the street"
     with  name 'city' 'buildings' 'skyscrapers' 'shops' 'apartments' 'cars',
@@ -227,7 +227,7 @@ a normal room, it would seem logical that the phone booth is actually a
 big box on the sidewalk; therefore we define a ``container`` set in the 
 street, which players may enter:
 
-.. code-block:: inform6
+.. code-block:: inform
 
   Appliance booth "phone booth" street
     with name 'old' 'red' 'picturesque' 'phone' 'booth' 'cabin'
@@ -270,7 +270,7 @@ intercept this attempt and redirect it (while we're at it, we add a
 connection to the as-yet-undefined café room and a default message for 
 the movement which is not allowed):
 
-.. code-block:: inform6
+.. code-block:: inform
 
   Room    street "On the street"
     with  name city' 'buildings' 'skyscrapers' 'shops' 'apartments' 'cars',
@@ -284,12 +284,6 @@ the movement which is not allowed):
               "No time now for exploring! You'll move much faster in your
                Captain FATE costume.";
 
-.. todo::
-
-   Notice how the syntax coloring thinks that the exclaimation point 
-   above is a comment.  This is another problem with the built-in inform6 
-   syntax colorer.
-
 That takes care of entering the booth. But what about leaving it? 
 Players may type EXIT or OUT while they are inside an enterable 
 container and the interpreter will oblige but, again, they might type 
@@ -297,7 +291,7 @@ NORTH. This is a problem, since we are actually in the street (albeit
 inside the booth) and to the north we have the café. We may provide for 
 this condition in the room's ``before`` property:
 
-.. code-block:: inform6
+.. code-block:: inform
 
   before [;
     Go:
@@ -310,7 +304,7 @@ connection. However, that would be an ambiguous command, for it could
 also refer to the café, so we express our bafflement and force the 
 player to try something else:
 
-.. code-block:: inform6
+.. code-block:: inform
 
   n_to cafe,
   s_to [; <<Enter booth>>; ],
@@ -342,7 +336,7 @@ the ``inside_description`` of the container. If the library decides we
 can’t see outside the container, only the inside_description is 
 displayed. Take for instance the following (simplified) example:
 
-.. code-block:: inform6
+.. code-block:: inform
 
   Room    stage "On stage"
     with  description
@@ -388,7 +382,7 @@ property of the ``street`` room a bit more complex, and change its
 value: instead of a string, we write an embedded routine. Here's the 
 (almost) finished room:
 
-.. code-block:: inform6
+.. code-block:: inform
 
   Room    street "On the street"
     with  name 'city' 'buildings' 'skyscrapers' 'shops' 'apartments' 'cars',
@@ -415,7 +409,7 @@ value: instead of a string, we write an embedded routine. Here's the
 The description while inside the booth mentions the sidewalk, which 
 might invite the player to EXAMINE it. No problem:
 
-.. code-block:: inform6
+.. code-block:: inform
 
   Appliance "sidewalk" street
     with  name sidewalk' 'pavement' 'street',
@@ -432,7 +426,7 @@ result of a LOOK action (which will have to do with the way the café
 looks from the *inside*); but while we are on the street we need 
 something else to describe it:
 
-.. code-block:: inform6
+.. code-block:: inform
 
   Appliance outside_of_cafe "Benny's cafe" street
     with  name 'benny^s' 'cafe' 'entrance',
@@ -448,42 +442,36 @@ something else to describe it:
           ],
     has   enterable proper;
 
-.. todo::
-
-   Figure out how to set off this entire note section as an indented block
+.. note::
 
-NOTE : although the text of our guide calls Benny's establishment a 
-"café" -- note the acute "e" -- the game itself simplifies this to 
-"cafe". We do this for clarity, not because Inform doesn't support 
-accented characters. The *Inform Designer's Manual* explains in detail 
-how to display these characters in "§1.11 *How text is printed*" and 
-provides the whole Z-machine character set in Table 2. In our case, we 
-could have displayed this::
+   although the text of our guide calls Benny's establishment a "café" 
+   -- note the acute "e" -- the game itself simplifies this to "cafe". 
+   We do this for clarity, not because Inform doesn't support accented 
+   characters. The *Inform Designer's Manual* explains in detail how to 
+   display these characters in "§1.11 *How text is printed*" and 
+   provides the whole Z-machine character set in Table 2. In our case, 
+   we could have displayed this::
 
-  The town's favourite for a quick snack, Benny's café has a 50's ROCKETSHIP look.
+      The town's favourite for a quick snack, Benny's café has a 50's ROCKETSHIP look.
 
-by defining the ``description`` property as any of these:
+   by defining the ``description`` property as any of these:
 
-.. code-block:: inform6
+   .. code-block:: inform
 
-  description
-      "The town's favourite for a quick snack, Benny's caf@'e has a 50's
-       ROCKETSHIP look.",
+     description
+         "The town's favourite for a quick snack, Benny's caf@'e has a 50's
+          ROCKETSHIP look.",
 
-  description
-      "The town's favourite for a quick snack, Benny's caf@@170 has a 50's
-       ROCKETSHIP look.",
+     description
+         "The town's favourite for a quick snack, Benny's caf@@170 has a 50's
+          ROCKETSHIP look.",
 
-  description
-      "The town's favourite for a quick snack, Benny's caf@{E9} has a 50's
-       ROCKETSHIP look.",
+     description
+         "The town's favourite for a quick snack, Benny's caf@{E9} has a 50's
+          ROCKETSHIP look.",
 
-However, all three forms are harder to read than the vanilla "cafe", so 
-we've opted for the simple life.
-
-.. todo::
-
-   Indented block ends here
+   However, all three forms are harder to read than the vanilla "cafe", so 
+   we've opted for the simple life.
 
 Unlike the sidewalk object, we offer more than a mere description. Since 
 the player may try ENTER CAFE as a reasonable way of access -- which 
@@ -504,7 +492,7 @@ out that it would be neater to handle the actual movement of the player
 in just one place of our code, because this helps clarity. To achieve 
 this, we redirect the street's ``n_to`` property thus:
 
-.. code-block:: inform6
+.. code-block:: inform
 
   n_to [; <<Enter outside_of_cafe>>; ],
 
@@ -552,7 +540,7 @@ responses. If nothing else, this adds to the general atmosphere, a
 nicety that many players regard as important. For this mission, we make 
 use of the ``LibraryMessages`` object.
 
-.. code-block:: inform6
+.. code-block:: inform
 
   Include "Parser";
 
@@ -605,52 +593,41 @@ of responses. The variable ``lm_n`` holds the current value of the
 number of the message to be displayed, so you can change the default 
 with a test like this:
 
-.. code-block:: inform6
+.. code-block:: inform
 
   if (lm_n == 39)
       "That's not something you need to refer to in order to SAVE the day.";
 
-.. todo::
-
-   That block of code above should be colored.  Is there a defect in the 
-   syntax coloring code?
-
 where 39 is the number for the standard message "That's not something 
 you need to refer to in the course of this game" -- displayed when the 
 player mentions a noun which is listed in a room's name property, as we 
 did for the ``street``.
 
-.. todo::
-
-   Begin big chunk of indented text. Also, NOTE should be in bigcaps.
-
-NOTE : remember that when we are testing for different values of the 
-same variable, we can also use the switch statement. For the Miscellany 
-entry, the following code would work just as nicely:
-
-.. code-block:: inform6
-
-  ...
-  Miscellany:
-    switch (lm_n) {
-      19:
-        if (clothes has worn)
-            "In your secret identity's outfit, you manage most
-             efficaciously to look like a two-cent loser, a
-             good-for-nothing wimp.";
-        else
-            "Now that you are wearing your costume, you project
-             the image of power UNBOUND, of ballooned,
-             multicoloured MUSCLE, of DASHING yet MODEST chic.";
-      38:
-        "That's not a verb you need to SUCCESSFULLY save the day.";
-      39:
-        "That's not something you need to refer to in order to SAVE the day.";
-    }
-
-.. todo::
-
-   End big indented chunk
+.. note::
+
+   Remember that when we are testing for different values of the 
+   same variable, we can also use the switch statement. For the 
+   Miscellany entry, the following code would work just as nicely:
+
+   .. code-block:: inform
+
+     ...
+     Miscellany:
+       switch (lm_n) {
+         19:
+           if (clothes has worn)
+               "In your secret identity's outfit, you manage most
+                efficaciously to look like a two-cent loser, a
+                good-for-nothing wimp.";
+           else
+               "Now that you are wearing your costume, you project
+                the image of power UNBOUND, of ballooned,
+                multicoloured MUSCLE, of DASHING yet MODEST chic.";
+         38:
+           "That's not a verb you need to SUCCESSFULLY save the day.";
+         39:
+           "That's not something you need to refer to in order to SAVE the day.";
+       }
 
 Not surprisingly, the default message for self-examination: "As good 
 looking as ever" is a ``Miscellany`` entry -- it's number 19 -- so we 
@@ -671,21 +648,19 @@ experience grows.
 
 .. todo::
 
-   Begin big indented chunk.  That "whatever new look" needs to be italicized.
+    That "whatever new look" below needs to be italicized and bolded for LaTeX
 
-NOTE: going back to our example, an alternative approach would be to set 
-the variable ``player.description`` in the ``Initialise`` routine (as we 
-did with "William Tell") to the "ordinary clothes" string, and then 
-later change it as the need arises. It is a variable, after all, and you 
-can alter its value with another statement like ``player.description = 
-*whatever new look*`` anywhere in your code. This alternative solution 
-might be better if we intended changing the description of the player 
-many times through the game. Since we plan to have only two states, the 
-``LibraryMessages`` approach will do just fine.
-
-.. todo::
+.. note::
 
-   End big indented chunk
+   going back to our example, an alternative approach would be to set 
+   the variable ``player.description`` in the ``Initialise`` routine (as we 
+   did with "William Tell") to the "ordinary clothes" string, and then 
+   later change it as the need arises. It is a variable, after all, and you 
+   can alter its value with another statement like ``player.description =`` 
+   *whatever new look* anywhere in your code. This alternative solution 
+   might be better if we intended changing the description of the player 
+   many times through the game. Since we plan to have only two states, the 
+   ``LibraryMessages`` approach will do just fine.
 
 A final warning: as we explained when extending the standard verb 
 grammars, you *could* edit the appropriate library file and change all