Merge pull request #16 from andrewschultz/inform7-typos

inform7/** typos

inform7/Manual/Calling Inform from C.w

@@ -455,7 +455,7 @@ Note that a header file called |inform7_symbols.h| is included. This defines
 useful constants like |i7_A_Take| (for the "taking" action) and |i7_I_Linear_B_tablet|
 (for the object called "Linear B tablet"). But where did this header come from?
 
-The answer is that this file can ootionally be created when //inform7// is
+The answer is that this file can optionally be created when //inform7// is
 generating C. In Example 5 we ran Inform with |-format=C/no-main|; this time
 we use |-format=C/no-main/symbols-header|. This also needs a subtle change to
 the makefile logic; the difference being that |Eg6-C.o| is now dependent on
@@ -477,7 +477,7 @@ Eg6-I.c: Eg6.i7
 
 Anyway, the result of this is:
 = (text as ConsoleText)
-Sir Arthur Evans, hero and archeologist, invites you to explore...
+Sir Arthur Evans, hero and archaeologist, invites you to explore...
 
 Welcome
 An Interactive Fiction

inform7/assertions-module/Chapter 3/New Literal Pattern Requests.w

@@ -22,7 +22,7 @@ Nobody who defines a literal pattern with the word "times" in can expect good
 results anyway, given that "times" will usually be interpreted as
 multiplication when Inform eventually parses such a literal.
 
-@ We create new literal pattenrs during pass 1, which imposes two timing
+@ We create new literal patterns during pass 1, which imposes two timing
 constraints:
 
 (a) The specification sentence must come after the sentence creating the

inform7/assertions-module/Chapter 5/Imperative Definitions.w

@@ -153,7 +153,7 @@ void ImperativeDefinitions::compile_first_block(void) {
 
 @h The body.
 During assessment, then, each //imperative_defn// is given a body, which
-is one of these. It reoresents the body of the definition -- that is, the
+is one of these. It represents the body of the definition -- that is, the
 Inform 7 source text written underneath the heading.
 
 =

inform7/assertions-module/Chapter 5/Phrase Options.w

@@ -6,11 +6,11 @@ with which the user can choose to invoke a To phrase.
 @h Introduction.
 A "phrase option" is a sort of modifier tacked on to an invocation of a
 phrase; the only modifiers allowed are those declared in that phrase's
-preamble. Phrase pptions are an early feature of Inform 7 going back to a
+preamble. Phrase options are an early feature of Inform 7 going back to a
 time when its priority was to enable the paraphrasing of Inform 6 library
 features (such as the bitmap passed as a parameter to the list-printer).
 
-I now sligjtly regret the existence of phrase options, but above all the
+I now slightly regret the existence of phrase options, but above all the
 comma-based syntax used for them, as here. Brackets would have been better;
 it makes phrase options impossible to use for text substitutions.
 

inform7/assertions-module/Chapter 6/Rule Bookings.w

@@ -24,7 +24,7 @@ typedef struct booking {
 	int placement; /* one of the |*_PLACEMENT| values above */
 	int place_automatically; /* should this be inserted automatically? */
 
-	struct booking_commentary commentary; /* used omly for indexing and code comments */
+	struct booking_commentary commentary; /* used only for indexing and code comments */
 
 	struct booking *next_booking; /* in its booking list */
 	CLASS_DEFINITION

inform7/assertions-module/Preliminaries/What This Module Does.w

@@ -85,7 +85,7 @@ making of the new activity.
 
 @h Regular meanings.
 As noted above, //Assertions::make_coupling// is called on each regular
-assertion: coupling being a lingistic term for placing subject and object into
+assertion: coupling being a linguistic term for placing subject and object into
 a relationship with each other. What it does is to split into cases according to
 the subject and object phrases of a sentence. These can take 12 different forms,
 so there are $12\times 12 = 144$ possible combinations of subject with object,

inform7/core-module/Chapter 1/Core Module.w

@@ -8,7 +8,7 @@ Setting up the use of this module.
 
 @ Like all modules, this one must define a |start| and |end| function.
 
-Note that the "core" plugin itself does nothihg except to be a parent to the
+Note that the "core" plugin itself does nothing except to be a parent to the
 other two; it doesn't even have an activation function.
 
 @e TASK_QUEUE_DA

inform7/core-module/Chapter 1/What To Compile.w

@@ -349,7 +349,7 @@ By default the story file will be called something like |story.z8|, but
 its leafname is actually declared from the source text of the Inform
 project created to do this wrapping-up. So we need a way to set as well
 as read this filename. Whatever the leafname, though, it lives in the top
-level of materuals.
+level of materials.
 
 =
 int Task::wraps_existing_storyfile(void) {

inform7/core-module/Chapter 2/Using Problems.w

@@ -6,7 +6,7 @@ Interface to the Problems module.
 
 @d PROBLEMS_HTML_EMITTER HTML::put
 
-@ In "silence-is-goldem" mode, we want our Problem messages to look more like
+@ In "silence-is-golden" mode, we want our Problem messages to look more like
 traditional Unix errors, even if they're long ones:
 
 @d FORMAT_CONSOLE_PROBLEMS_CALLBACK Problems::Using::console_format

inform7/core-module/Chapter 3/Plugin Calls.w

@@ -359,7 +359,7 @@ int PluginCalls::new_base_kind_notify(kind *K, kind *super, text_stream *d, word
 been created. For example, the figures plugin needs to know this so that it
 can see when a new illustration has been created.
 
-At the time this is called, the exact kind of an instance may not be knowm,
+At the time this is called, the exact kind of an instance may not be known,
 if that instance is an object: so beware of relying on the kind unless you're
 sure you're not dealing with an object.
 

inform7/extensions/basic_inform/Sections/Phrase Definitions.w

@@ -43,7 +43,7 @@ produce Inform 6 code. That is not so: they produce Inter code, which
 can then be translated as needed.
 
 Most of the definitions here also have annotations to positions in the
-main Inform dcumentation: for example, |(documented at phs_s)|. This has
+main Inform documentation: for example, |(documented at phs_s)|. This has
 no effect on the code compiled, and is used only when Inform generates
 certain problem messages; if the source text misuses the phrase, the problem
 can then give a reference to the relevant documentation. |phs_s| is a

inform7/extensions/standard_rules/Sections/Phrase Definitions.w

@@ -638,7 +638,7 @@ To decide whether player consents
 		(- YesOrNo() -).
 
 @ Support for snippets, which are substrings of the player's command. This
-is a kind of value which doesm't exist in Basic Inform.
+is a kind of value which doesn't exist in Basic Inform.
 
 =
 Section 2 - The player's command

inform7/extensions/standard_rules/Sections/Physical World Model.w

@@ -365,7 +365,7 @@ interpretation of words like "inside" which might refer either to the
 Of the rest, N/S, NE/SW, E/W, SE/NW and U/D, it's noteworthy that this
 choice imposes a cubical grid on the world, simply because the compass
 directions are at 45 and 90 degree angles to each other: a hexagonal
-tessalation would be more faithful to distances (it would get rid of the
+tessellation would be more faithful to distances (it would get rid of the
 awkward point that a NE move is root 2 times the length of a N move),
 but in practice the world model doesn't care much about distances, another
 example of its qualitative nature. A further point is that, in a

inform7/extensions/standard_rules/Sections/Preamble.w

@@ -36,7 +36,7 @@ The verb to index map with in the imperative means the built-in index-map-with m
 
 @h Use Options.
 In fact, many of the definitions below are handled slightly differently in
-the |srules| template files, to avoid the need for conditional compilatipn
+the |srules| template files, to avoid the need for conditional compilation
 (and thus to enable the template to be assimilated just once); but we
 continue to give them the traditional constant names, for the sake of any
 third-party extensions using these.

inform7/if-module/Chapter 3/Map Connection Relations.w

@@ -73,7 +73,7 @@ as a direction name plus "of", since "below" is not the name of the direction
 	... from
 
 @ Two of the directions are special to mapping, because they have to be parsed
-slighly differently. (These are the English names; there is no need to translate
+slightly differently. (These are the English names; there is no need to translate
 this to other languages.)
 
 =

inform7/if-module/Chapter 4/Actions Plugin.w

@@ -17,7 +17,7 @@ represented by //explicit_action// objects.
 (*) An "action name" -- not an ideal thing to call it, but traditional -- is the
 type of action involved, taken in isolation: for example, "taking". These can
 also be values at run-time, they have kind |K_action_name|, and they are
-represented in the comoiler by //action_name// objections.
+represented in the compiler by //action_name// objections.
 (*) An "action pattern" is a textual description which matches some actions but
 not others, and can be vague or specific: for example, "wearing or examining
 something". Action patterns become values of the kind |K_description_of_action|.

inform7/if-module/Chapter 4/Explicit Actions.w

@@ -2,7 +2,7 @@
 
 An exactly specified action is called "explicit".
 
-@ Explicit actions are used inside the compiler whenever we kmow exactly what
+@ Explicit actions are used inside the compiler whenever we know exactly what
 action we are talking about; stored action constants are //explicit_action//
 objects in a thin wrapper -- see //Action Kinds//.
 

inform7/if-module/Chapter 4/Parse Clauses.w

@@ -205,7 +205,7 @@ to typecheck each clause.
 		LOG_OUTDENT;
 	}
 
-@ This is where heterogenous patterns like "dropping a thing or taking a
+@ This is where heterogeneous patterns like "dropping a thing or taking a
 container" are thrown out: only the last-placed action is allowed to have
 clauses.
 

inform7/if-module/Chapter 5/Command Grammar Lines.w

@@ -625,7 +625,7 @@ some can never happen. For example,
 ask [someone] about [something]
 ask [someone] about [text]
 =
-have to be that way around, because any comnand which matches the first line
+have to be that way around, because any command which matches the first line
 here also matches the second. Putting these lines into order used to be part
 of the craft of the Inform 6 programmer, but it was always difficult to do,
 and Inform 7 aimed to liberate authors from the need to do this. A long
@@ -651,7 +651,7 @@ int CGLines::cg_line_must_precede(command_grammar *cg, cg_line *L1, cg_line *L2)
 	@<Higher sort bonuses precede lower ones@>;
 	@<More specific determinations precede less specific ones@>;
 	@<Conditional readings precede unconditional readings@>;
-	@<Lines created earlier precede lines creater later in the source text@>;
+	@<Lines created earlier precede lines created later in the source text@>;
 }
 
 @<Perform some sanity checks@> =
@@ -686,7 +686,7 @@ working through a |CG_IS_COMMAND| grammar -- it always knows how many words
 it has to match. If the player has typed TAKE FROG FROM AQUARIUM, the parser
 has to make sense of all of the words. It needs to consider the possibility
 "take [something]" before "take [something] from [something]" because there
-might be an object called "frog fram aquarium".
+might be an object called "frog from aquarium".
 
 On the other hand, if it is parsing a |CG_IS_TOKEN| grammar, it is trying to
 match as many words as possible from a stream of words that will probably then
@@ -771,6 +771,6 @@ an object has a name like ON VISION ON -- perhaps a book about the antique
 BBC children's television programme "Vision On" -- so that the command
 TURN ON VISION ON would match both of the alternative CGLs.
 
-@<Lines created earlier precede lines creater later in the source text@> =
+@<Lines created earlier precede lines created later in the source text@> =
 	if (L1->allocation_id < L2->allocation_id) return TRUE;
 	return FALSE;

inform7/imperative-module/Chapter 2/Compile Values.w

@@ -209,7 +209,7 @@ parse_node *CompileValues::cast_nonconstant(parse_node *value, kind *K_wanted,
 	return value;
 }
 
-@ Certain kinds of value cannot be used on every virtual machine; for examole,
+@ Certain kinds of value cannot be used on every virtual machine; for example,
 the Z-machine does not support real numbers.
 
 =

inform7/imperative-module/Chapter 2/Matching Action Patterns.w

@@ -344,7 +344,7 @@ in the range |ACTOR_IS_PLAYER_CPMC <= N <= ACTOR_MATCHES_CPMC|, and so on.
 @ This is the easier case: all four ranges of condition must be true, and so
 we compile code equivalent to |ACTION and ACTOR and DETAILS and WHEN|. We
 do it in that order for two reasons: firstly, wrong actions are the commonest
-reasom actions fail to match, and the ACTION tests are quick, so it's efficient
+reason actions fail to match, and the ACTION tests are quick, so it's efficient
 to test that first. (The ACTOR tests are also quick, but usually pass.) Secondly,
 some DETAILS tests will compile non-typesafe code in cases where ACTION would
 not pass, so DETAILS must be compiled after ACTION. Finally, we put WHEN at
@@ -395,7 +395,7 @@ we still have to compile |true|, to ensure that every action will match.
 @ A listwise negated pattern is something like "doing something other than
 examining the box", which matches any action except "examining the box". It
 might seem that this could be negated just as the negation of the positive
-case, but that overlookz the hidden clauses about who the actor is, whether
+case, but that overlooks the hidden clauses about who the actor is, whether
 the action is a request, and so on -- the |ACTOR_CPMCRANGE| -- and any
 condition supplied -- the |WHEN_CPMCRANGE|.
 

inform7/imperative-module/Chapter 2/Matching Going Action Patterns.w

@@ -53,7 +53,7 @@ ordinarily a direction.)
 
 @ The not-nowhere test is needed for patterns like "going from the Dining Room",
 which we want to match only where there is some destination: i.e., we don't want
-it to match an attemot to go in a direction not available in the map.
+it to match an attempt to go in a direction not available in the map.
 
 @<Compile NOT_NOWHERE_CPMC test@> =
 	EmitCode::inv(NE_BIP);

inform7/imperative-module/Chapter 3/Functions.w

@@ -4,7 +4,7 @@ To compile Inter functions.
 
 @ The code in this section is used throughout the //imperative// and //runtime//
 modules whenever an Inter function needs to be compiled. This will often not be
-a function corresponding to a definition in the soruce text; more often, it will
+a function corresponding to a definition in the source text; more often, it will
 be a support function needed to implement some feature at runtime.
 
 However it happens, every function is compiled using code like so:

inform7/imperative-module/Chapter 3/Stack Frames.w

@@ -19,7 +19,7 @@ about the function currently being compiled. In particular:
 (*) what kind of value we should be returning, if anything.
 
 @ Code can only be compiled "inside" a stack frame, and at any given time
-(when code is being comoiled, anyway) there is a "current" frame.
+(when code is being compiled, anyway) there is a "current" frame.
 
 =
 stack_frame *current_frame = NULL;

inform7/imperative-module/Chapter 5/Compile Blocks and Lines.w

@@ -7,7 +7,7 @@ As this section of code opens, we are looking at the parse tree for the body
 of a rule or phrase definition. A request has been made to compile (a version of)
 this into an Inter function; the stack frame for that has been sorted out, and
 the function begun. Now we must compile the actual code to go into the function;
-the test grpup |:invocations| exercises all of this.
+the test group |:invocations| exercises all of this.
 
 Here is a typical example rule, taken from the Standard Rules:
 = (text as Inform 7)
@@ -21,7 +21,7 @@ Report an actor waiting (this is the standard report waiting rule):
 =
 In the parse tree, this now looks like so:
 = (text)
-IMPERATIVE_NT'report an actor waiting ( this is the standard report waitin'
+IMPERATIVE_NT'report an actor waiting ( this is the standard report waiting'
 	CODE_BLOCK_NT
 		CODE_BLOCK_NT
 			INVOCATION_LIST_NT'if the actor is the player'
@@ -825,7 +825,7 @@ void CompileBlocksAndLines::verify_say_node_list(parse_node *say_node_list) {
 		StandardProblems::sentence_problem(Task::syntax_tree(),
 			_p_(PM_SayOverComplex),
 			"this is too complex a text substitution",
-			"and needs to be simplified. You might find it helful to define a new text "
+			"and needs to be simplified. You might find it hel[ful to define a new text "
 			"substitution of your own ('To say fiddly details: ...') and then use it "
 			"in this text by including the '[fiddly details]'.");
 		problem_issued = TRUE;

inform7/imperative-module/Chapter 5/Compile Invocations Inline.w

@@ -39,7 +39,7 @@ front material before compiling the block, and the back material afterwards.
 
 @ The process of compiling from an inline definition is a little like
 interpreting a program, and a //csi_state// object represents the state of
-tbe (imaginary) computer doing that.
+the (imaginary) computer doing that.
 
 =
 typedef struct csi_state {
@@ -160,7 +160,7 @@ unless a code block is opened: if it is, then they're deallocated when it ends.
 		if (CSIS.my_vars[i])
 			LocalVariableSlates::deallocate_I7_local(CSIS.my_vars[i]);
 
-@ And tbis is what happens when the back part of the definition is finally
+@ And this is what happens when the back part of the definition is finally
 compiled.
 
 =
@@ -179,7 +179,7 @@ the schema, and calls //CSIInline::from_source_text// on any material enclosed
 in |(+ ... +)| notation.
 
 |CSIS| is passed to this function as our "opaque state" -- meaning that it is
-passed through unchanged to our callbach functions, and means that the code
+passed through unchanged to our callback functions, and means that the code
 below can share some private state variables.
 
 =

inform7/knowledge-module/Chapter 3/Either-Or Properties.w

@@ -7,7 +7,7 @@ attached.
 Either-or properties may need rather different run-time implementation from
 properties with values, but otherwise they might seem nothing special: why
 not simply regard them as properties holding truth state values? And then
-there would just be obe type of property.
+there would just be one type of property.
 
 The answer is that whereas a computer-science view of the "open" property,
 say, would take exactly this line -- i.e., that it simply holds a truth

inform7/knowledge-module/Chapter 4/Kind Subjects.w

@@ -94,7 +94,7 @@ void KindSubjects::renew(kind *K, kind *super, wording W) {
 
 @ Even base kinds which do have subjects do not necessarily allow properties
 to be given to their values -- "number", for instance, where you cannot give
-a property to the nunber 6.
+a property to the number 6.
 
 In general a value can have properties if and only if its kind passes this test:
 

inform7/knowledge-module/Chapter 4/Property Permissions.w

@@ -40,7 +40,7 @@ are equivalent here: permission for one is always permission for the other.
 
 If these were long lists, or searched often, it would be faster to move each
 found permission to the front, thus tending to move frequently-sought properties
-to the start. Pofiling shows that this would save no significant time,
+to the start. Profiling shows that this would save no significant time,
 whereas the unpredictable order might make testing Inform more annoying.
 
 @d LOOP_OVER_PERMISSIONS_FOR_PROPERTY(pp, prn)

inform7/knowledge-module/Chapter 5/The Naming Thicket.w

@@ -286,7 +286,7 @@ source text description, so that "Mr Beebe" will not be flattened to "mr
 beebe"; but that we take care to reduce the case of "Your nose" (etc.)
 to "your nose", unless it occurs in the name of a room, like "Your Bedroom".
 
-If the "spatial" plugin is inactive, |this_is_a_room| is akways |FALSE|.
+If the "spatial" plugin is inactive, |this_is_a_room| is always |FALSE|.
 
 @<Compose the I6 short-name as a piece of text@> =
 	Naming::compose_words_to_I6_naming_text(textual_value, W, FALSE,

inform7/multimedia-module/Chapter 1/Multimedia Module.w

@@ -10,7 +10,7 @@ which use this module:
 
 @ Like all modules, this one must define a |start| and |end| function.
 
-Note that the "multimedia" plugin itself does nothihg except to be a parent
+Note that the "multimedia" plugin itself does nothing except to be a parent
 to the other three; it doesn't even have an activation function.
 
 @e MULTIMEDIA_CREATIONS_DA

inform7/runtime-module/Chapter 2/Emit Code.w

@@ -166,7 +166,7 @@ int EmitCode::cast_possible(kind *F, kind *T) {
 }
 
 @ Casts are in many cases implicit, so that nothing need be done, and the
-followimg simply returns |TRUE| to indicate success. But in a few cases, a
+following simply returns |TRUE| to indicate success. But in a few cases, a
 function call must be inserted, with a name like |SNIPPET_TY_to_TEXT_TY|;
 in such cases, this function must exist in the kits somewhere.
 

inform7/runtime-module/Chapter 2/Equality Schemas.w

@@ -1,6 +1,6 @@
 [EqualitySchemas::] Equality Schemas.
 
-To define how to compile a comparisom of two values.
+To define how to compile a comparison of two values.
 
 @ For most word-value kinds, it's easy to compare two values to see if they are
 equal: all we need is the |==| operator. But for pointer-value kinds, that

inform7/runtime-module/Chapter 2/Here, Nowhere and Everywhere.w

@@ -1,6 +1,6 @@
 [RTSpatial::] Here, Nowhere and Everywhere.
 
-Almost a Beatles song, but really a set of schemas for compilimg the meaning
+Almost a Beatles song, but really a set of schemas for compiling the meaning
 of the unary predicates here, nowhere and everywhere.
 
 @ Here. In fact, at present "here" predicates are never included in propositions to

inform7/runtime-module/Chapter 5/Actions.w

@@ -80,7 +80,7 @@ inter_name *RTActions::base_iname(action_name *an) {
 @ We actually want the other names to still be related to the base name even
 after a translation; i.e., if an action is translated to |Grab|, then we want
 to have the related names be |##Grab| and |GrabSub|. So translation needs to
-happen early-ish in the run, befpre tbe base iname is generated.
+happen early-ish in the run, before the base iname is generated.
 
 =
 void RTActions::translate(action_name *an, wording W) {

inform7/runtime-module/Chapter 5/Adjectives.w

@@ -424,7 +424,7 @@ void RTAdjectives::make_adjective_phrase_package(id_body *idb) {
 
 @h Compiling tasks for adjectives defined by I7 or Inter code.
 First, an adjective defined by a condition written in raw Inter code can be
-tested (but not asserted) using a schema, since those are also raw Inter coce.
+tested (but not asserted) using a schema, since those are also raw Inter code.
 All we do is remove the enrobing quotation marks around the condition.
 
 =

inform7/runtime-module/Chapter 5/Conjugations.w

@@ -58,7 +58,7 @@ package_request *RTVerbs::modal_package(parse_node *where) {
 	return Hierarchy::local_package_to(MVERBS_HAP, where);
 }
 
-@h Compilation data for conjgations.
+@h Compilation data for conjugations.
 Each |verb_conjugation| object contains this data:
 
 @d VC_COMPILATION_LINGUISTICS_CALLBACK RTVerbs::initialise_vc

inform7/runtime-module/Chapter 5/Rules.w

@@ -123,7 +123,7 @@ inter_name *RTRules::shell_iname(rule *R) {
 }
 
 @ Note that the response handler function must be made available to the linker,
-because the idea is that the kit function will use it. For examole, the code
+because the idea is that the kit function will use it. For example, the code
 in the kit might read like so:
 = (text as Inform 6)
 [ MY_FOREIGN_R;