Index: pages/affcase1.in
==================================================================
--- pages/affcase1.in
+++ pages/affcase1.in
@@ -7,11 +7,11 @@
 
 <h2>Introduction</h2>
 
 <p>Suppose the
 [http://en.wikipedia.org/wiki/OpenDocument|OpenDocument] file format,
-and specifically the "ODP" OpenDocument Presentation format, where
+and specifically the "ODP" OpenDocument Presentation format, were
 built around SQLite.  Benefits would include:
 <ul>
 <li>Smaller documents
 <li>Faster File/Save times
 <li>Faster startup times
@@ -465,11 +465,11 @@
 <ul>
 <li> Store an [automated undo/redo stack] in a database table so that
      Undo could go back into prior edit sessions.
 <li> Add [FTS4|full text search] capabilities to the slide deck, or across
      multiple slide decks.
-<li> Decompose the "settings.xml" file into an SQL table kind that
+<li> Decompose the "settings.xml" file into an SQL table that
      is more easily viewed and edited by separate applications.
 <li> Break out the "Presentor Notes" from each slide into a separate
      table, for easier access from third-party applications and/or scripts.
 <li> Enhance the presentation concept beyond the simple linear sequence of
      slides to allow for side-tracks and excursions to be taken depending on

Index: pages/howtocorrupt.in
==================================================================
--- pages/howtocorrupt.in
+++ pages/howtocorrupt.in
@@ -411,11 +411,11 @@
 <p>The following are examples of disabling the built-in protection
 mechanisms of SQLite:
 
 <ul>
 <li><p>Setting [PRAGMA synchronous=OFF] can cause the database to
-go corrupt if there is an operating-system crass or power failure,
+go corrupt if there is an operating-system crash or power failure,
 though this setting is safe from damage due to application crashes.
 
 <li><p>Changing the [PRAGMA schema_version] while other database
 connections are open.
 

Index: pages/inmemorydb.in
==================================================================
--- pages/inmemorydb.in
+++ pages/inmemorydb.in
@@ -116,13 +116,14 @@
 databases each have their own private database.  Temporary databases are
 automatically deleted when the connection that created them closes.</p>
 
 <p>Even though a disk file is allocated for each temporary database, in
 practice the temporary database usually resides in the in-memory pager
-cache and hence is very little difference between a pure in-memory database
+cache and hence there is very little difference between a pure in-memory
+database
 created by ":memory:" and a temporary database created by an empty filename.
-The sole difference is that a ":memory:" database must remain in memory
+The only difference is that a ":memory:" database must remain in memory
 at all times whereas parts of a temporary database might be flushed to
 disk if database becomes large or if SQLite comes under memory pressure.</p>
 
 <p>The previous paragraphs describe the behavior of temporary databases
 under the default SQLite configuration.  An application can use the

Index: pages/json1.in
==================================================================
--- pages/json1.in
+++ pages/json1.in
@@ -21,11 +21,11 @@
   set fx [string trim $fx]
   set hlink "<a href='#$lnk'>"
   regsub -all {^json\(} $fx "${hlink}json</a>(" fx
   regsub -all {(json_[a-z_]+)} $fx "$hlink\\1</a>" fx
   regsub -all {(value[1-9]?|path|label[1-9]?)} $fx "<i>\\1</i>" fx
-  regsub -all {\((json)} $fx "(<i>\\1</i>" fx
+  regsub -all {(json[1-9]?|name)} $fx "<i>\\1</i>" fx
   hd_puts "$fx\n"
   # hd_puts "[string trim $desc]\n"
   hd_puts "</li>\n\n"
 }
 set tsctr 100

Index: pages/prosupport.in
==================================================================
--- pages/prosupport.in
+++ pages/prosupport.in
@@ -242,11 +242,11 @@
 an as-deployed configuration using only published and documented interfaces.
 TH3 is designed for use with embedded devices, and is compatible with
 DO-178B.  Every release of the public-domain SQLite is tested using TH3,
 and so all users benefit from the TH3 tests.  But the TH3 tests are not
 themselves public.  Hardware or system manufactures who want to have
-TH3 test run on their systems can negotiation a service agreement to have
+TH3 test run on their systems can negotiate a service agreement to have
 the SQLite Developers run those tests.</p>
 
 <h2>About The SQLite Team</h2>
 
 <p>Paid support options and products are provided by

Index: pages/vfs.in
==================================================================
--- pages/vfs.in
+++ pages/vfs.in
@@ -191,11 +191,11 @@
 
 <li><p>
 [http://www.sqlite.org/src/doc/trunk/src/test_quota.c | test_quota.c] - 
 This file implements a shim called "quota" that enforces cumulative
 file size limits on a collection of database files.  An auxiliary
-interface is used to define "quote groups".  A quota group is a
+interface is used to define "quota groups".  A quota group is a
 set of files (database files, journals, and temporary files) whose
 names all match a [GLOB] pattern.  The sum of the sizes of all files
 in each quota group is tracked, and if that sum exceeds a threshold
 defined for the quota group, a callback function is invoked.  That
 callback can either increase the threshold or cause the operation

Index: search/search.tcl
==================================================================
--- search/search.tcl
+++ search/search.tcl
@@ -402,10 +402,11 @@
   return $ret
 }
 
 proc main {} {
   global A
+  set A(s) d
   cgi_parse_args
 
   # If "env=1" is specified, dump the environment variables instead
   # of running any search.
   if {[info exists ::A(env)]} { return [cgi_env_dump] }