Fix mistakes

doc/rationale.qbk

@@ -202,7 +202,7 @@ It has a different API, and other code that operates on text expects a string
 instead of some other container.  Arrays of characters are already considered
 special by the standard library and common practice in C++.
 
-Second, When you write a parser that parses multiple characters in a row, you
+Second, when you write a parser that parses multiple characters in a row, you
 are typically trying to produce a string attribute, rather than a few
 individual character values.  When you use multiple non-character parsers in a
 row, you are typically trying to produce multiple values.  For instance:
@@ -217,7 +217,7 @@ I've rarely written a parser like `parser_2` and wanted a
 `std::vector<std::string>`.
 
 _Parser_ therefore makes the common case the default behavior, and provides
-you with the _merge_ and _sep_ directives to let you opt-in to generating the
+you with the _merge_ and _sep_ directives to let you opt in to generating the
 less-common attributes.
 
 [heading Attribute compatibility rules are more strict than in Spirit]
@@ -267,7 +267,7 @@ remember, and this is complicated to implement and maintain.
 
 I've been using Spirit 1 and later Spirit 2 since they were released.  I did
 not know about the particular looseness discussed here; a user pointed it out
-on Github.  In many years of using these libraries, I never fully learned all
+on GitHub.  In many years of using these libraries, I never fully learned all
 the attribute-compatibility rules, and was often surprised by them.
 
 Having a small set of rules that the user can internalize is vital; if the
@@ -299,7 +299,7 @@ that it succeeds (if it had failed, it would have cleared its attribute).  It
 does not know that there is nothing after it that could continue the parse,
 nor that it is being used in to do a full parse.  So, the over-all parse
 fails, but the part of the parse that fills in the out-param attribute does
-not know do clear its attribute.
+not know to clear its attribute.
 
 This is why the explicit clearing behavior happens at the end of _p_.  This is
 not without its downsides, though.  Consider this.
@@ -315,7 +315,7 @@ not without its downsides, though.  Consider this.
 Here, the explicit clearing replaces the previous value of `3`, even though
 the parser never touched the value!  Destroying users' variables' state
 without need may seem like a bad idea, but consider the alternative _emdash_
-In the previous example, we had spurious values left in the out-param
+in the previous example, we had spurious values left in the out-param
 attribute.  Here, without clearing, we would have had a value left in the
 out-param attribute, not because it was a partial result of the parse, but
 because the parse never touched it.  This is certain to be confusing, or at
@@ -338,7 +338,7 @@ They do not even work correctly for ASCII values.  This is because they use
 the C standard library's locale mechanism, which can be set to anything the
 current platform supports, and can be set by any code anywhere in your
 program; the locale is mutable global state.  So, even if you use the default
-"C locale in your program, if you link against a library that sets the locale
+C locale in your program, if you link against a library that sets the locale
 to something that breaks ASCII character recognition (an EBCDIC locale, for
 instance), your program is now incorrect, regardless of the code you wrote.
 

doc/tables.qbk

@@ -80,7 +80,7 @@ the input they match unless otherwise stated in the table below.]
     [[ _attr_np_`(arg0)` ]
      [ Always matches, and consumes no input.  Generates the attribute `_RES_np_(arg0)`. ]
      [ `decltype(_RES_np_(arg0))`. ]
-     [ An important use case for `_attr_` is to provide a default attribute value as a trailing alternative.  For instance, an *optional* comma-delmited list is: `int_ % ',' | attr(std::vector<int>)`.  Without the "`| attr(...)`", at least one `int_` match would be required. ]]
+     [ An important use case for `_attr_` is to provide a default attribute value as a trailing alternative.  For instance, an *optional* comma-delimited list is: `int_ % ',' | attr(std::vector<int>)`.  Without the "`| attr(...)`", at least one `int_` match would be required. ]]
 
     [[ _ch_ ]
      [ Matches any single code point. ]
@@ -138,7 +138,7 @@ the input they match unless otherwise stated in the table below.]
      []]
 
     [[ `_hex_digit_` ]
-     [ Matches a single hexidecimal digit code point. ]
+     [ Matches a single hexadecimal digit code point. ]
      [ The code point type in Unicode parsing, or `char` in non-Unicode parsing.  See the entry for _ch_. ]
      []]
 
@@ -328,7 +328,7 @@ the input they match unless otherwise stated in the table below.]
      [ It is an error to write `_sw_np_(arg0)`.  That is, it is an error to omit the conditionally matched parsers `p1`, `p2`, .... ]]
 
     [[ _symbols_t_ ]
-     [ _symbols_ is an associative container of key, value pairs.  Each key is a _std_str_ and each value has type `T`.  In the Unicode parsing path, the strings are considered to be UTF-8 encoded; in the non-Unicode path, no encoding is assumed.  _symbols_ Matches the longest prefix `pre` of the input that is equal to one of the keys `k`.  If the length `len` of `pre` is zero, and there is no zero-length key, it does not match the input.  If `len` is positive, the generated attribute is the value associated with `k`.]
+     [ _symbols_ is an associative container of key, value pairs.  Each key is a _std_str_ and each value has type `T`.  In the Unicode parsing path, the strings are considered to be UTF-8 encoded; in the non-Unicode path, no encoding is assumed.  _symbols_ matches the longest prefix `pre` of the input that is equal to one of the keys `k`.  If the length `len` of `pre` is zero, and there is no zero-length key, it does not match the input.  If `len` is positive, the generated attribute is the value associated with `k`.]
      [ `T` ]
      [ Unlike the other entries in this table, _symbols_ is a type, not an object. ]]
 
@@ -368,7 +368,7 @@ character type (or use _attr_ to do so).]
 ]
 
 [template table_combining_operations
-Here are all the operator overloaded for parsers.  In the tables below:
+Here are all the operators overloaded for parsers.  In the tables below:
 
 * `c` is a character of type `char` or `char32_t`;
 
@@ -399,7 +399,7 @@ consume the input they match unless otherwise stated in the table below.]
     [[`p1 | p2`] [ Matches iff either `p1` matches or `p2` matches. ] [`std::variant<_ATTR_np_(p1), _ATTR_np_(p2)>` (See note.)] [ `|` is associative; `p1 | p2 | p3`, `(p1 | p2) | p3`, and `p1 | (p2 | p3)` are all equivalent.  This attribute type only applies to the case where `p1` and `p2` both generate attributes, and where the attribute types are different; see _attr_gen_ for the full rules. ]]
     [[`p | c`] [ Equivalent to `p | lit(c)`. ] [`_ATTR_np_(p)`] []]
     [[`p | r`] [ Equivalent to `p | lit(r)`. ] [`_ATTR_np_(p)`] []]
-    [[`p1 || p2`] [ Matches iff `p1` matches and `p2` matches, regardless of the order they match in. ] [`_bp_tup_<_ATTR_np_(p1), _ATTR_np_(p2)>`] [ `||` is associative; `p1 || p2 || p3`, `(p1 || p2) || p3`, and `p1 || (p2 || p3)` are all equivalent.  It is an error to include a _e_ (conditional or non-conditional) in an `operator||` expression.  Though the parsers are matched in any order, the attribute elements are always in the order written in the `operator||` expression. ]]
+    [[`p1 || p2`] [ Matches iff `p1` matches and `p2` matches, regardless of the order they match in. ] [`_bp_tup_<_ATTR_np_(p1), _ATTR_np_(p2)>`] [ `||` is associative; `p1 || p2 || p3`, `(p1 || p2) || p3`, and `p1 || (p2 || p3)` are all equivalent.  It is an error to include an _e_ (conditional or non-conditional) in an `operator||` expression.  Though the parsers are matched in any order, the attribute elements are always in the order written in the `operator||` expression. ]]
     [[`p1 - p2`] [ Equivalent to `!p2 >> p1`. ] [`_ATTR_np_(p1)`] []]
     [[`p - c`] [ Equivalent to `p - lit(c)`. ] [`_ATTR_np_(p)`] []]
     [[`p - r`] [ Equivalent to `p - lit(r)`. ] [`_ATTR_np_(p)`] []]