Updates to the repository README.md file.

FossilOrigin-Name: 7bfd3ab7996bf869eb2705495f3f2cd8bd6d1f4d029a1f26041e95049a9bfd3b

README.md

@@ -34,7 +34,9 @@ archives as follows:
 If you do want to use Fossil to check out the source tree, 
 first install Fossil version 2.0 or later.
 (Source tarballs and precompiled binaries available
-[here](https://www.fossil-scm.org/fossil/uv/download.html).)
+[here](https://www.fossil-scm.org/fossil/uv/download.html).  Fossil is
+a stand-alone program.  To install, simply download or build the single 
+executable file and put that file someplace on your $PATH.)
 Then run commands like this:
 
         mkdir ~/sqlite
@@ -106,19 +108,22 @@ The makefiles also require AWK.
 
 ## Source Code Tour
 
-Most of the core source files are in the **src/** subdirectory.  But
-src/ also contains files used to build the "testfixture" test harness;
-those file all begin with "test".  And src/ contains the "shell.c" file
-which is the main program for the "sqlite3.exe" command-line shell and
-the "tclsqlite.c" file which implements the bindings to SQLite from the
-Tcl programming language.  (Historical note:  SQLite began as a Tcl
+Most of the core source files are in the **src/** subdirectory.  The
+**src/** folder also contains files used to build the "testfixture" test
+harness. The names of the source files used "by testfixture" all begin
+with "test".
+The **src/** also contains the "shell.c" file
+which is the main program for the "sqlite3.exe"
+[command-line shell](https://sqlite.org/cli.html) and
+the "tclsqlite.c" file which implements the
+[TCL bindings](https://sqlite.org/tclsqlite.html) for SQLite.
+(Historical note:  SQLite began as a Tcl
 extension and only later escaped to the wild as an independent library.)
 
 Test scripts and programs are found in the **test/** subdirectory.
-There are other test suites for SQLite (see
-[How SQLite Is Tested](http://www.sqlite.org/testing.html))
-but those other test suites are
-in separate source repositories.
+Addtional test code is found in other source repositories.
+See [How SQLite Is Tested](http://www.sqlite.org/testing.html) for
+additional information.
 
 The **ext/** subdirectory contains code for extensions.  The
 Full-text search engine is in **ext/fts3**.  The R-Tree engine is in
@@ -142,7 +147,7 @@ manually-edited files and automatically-generated files.
 The SQLite interface is defined by the **sqlite3.h** header file, which is
 generated from src/sqlite.h.in, ./manifest.uuid, and ./VERSION.  The
 [Tcl script](http://www.tcl.tk) at tool/mksqlite3h.tcl does the conversion.
-The manifest.uuid file contains the SHA1 hash of the particular check-in
+The manifest.uuid file contains the SHA3 hash of the particular check-in
 and is used to generate the SQLITE\_SOURCE\_ID macro.  The VERSION file
 contains the current SQLite version number.  The sqlite3.h header is really
 just a copy of src/sqlite.h.in with the source-id and version number inserted
@@ -175,6 +180,13 @@ that maps SQL language keywords (ex: "CREATE", "SELECT", "INDEX", etc.) into
 the numeric codes used by the parse.c parser.  The keywordhash.h file is
 generated by a C-language program at tool mkkeywordhash.c.
 
+Th3 **pragma.h** header file contains various definitions used to parse
+and implement the PRAGMA statements.  The header is generated by a
+script **tool/mkpragmatab.tcl**. If you want to add a new PRAGMA, edit
+the **tool/mkpragmatab.tcl** file to insert the information needed by the
+parser for your new PRAGMA, then run the script to regenerate the
+**pragma.h** header file.
+
 ### The Amalgamation
 
 All of the individual C source code and header files (both manually-edited
@@ -192,7 +204,7 @@ subdirectory (using the equivalent of "make target_source") then the
 tool/mksqlite3c.tcl script is run to copy them all together in just the
 right order while resolving internal "#include" references.
 
-The amalgamation source file is more than 100K lines long.  Some symbolic
+The amalgamation source file is more than 200K lines long.  Some symbolic
 debuggers (most notably MSVC) are unable to deal with files longer than 64K
 lines.  To work around this, a separate Tcl script, tool/split-sqlite3c.tcl,
 can be run on the amalgamation to break it up into a single small C file
@@ -209,14 +221,15 @@ See the [architectural description](http://www.sqlite.org/arch.html)
 for details. Other documents that are useful in
 (helping to understand how SQLite works include the
 [file format](http://www.sqlite.org/fileformat2.html) description,
-the [virtual machine](http://www.sqlite.org/vdbe.html) that runs
+the [virtual machine](http://www.sqlite.org/opcode.html) that runs
 prepared statements, the description of
 [how transactions work](http://www.sqlite.org/atomiccommit.html), and
 the [overview of the query planner](http://www.sqlite.org/optoverview.html).
 
-Unfortunately, years of effort have gone into optimizating SQLite, both
+Years of effort have gone into optimizating SQLite, both
 for small size and high performance.  And optimizations tend to result in
-complex code.  So there is a lot of complexity in the SQLite implementation.
+complex code.  So there is a lot of complexity in the current SQLite
+implementation.  It will not be the easiest library in the world to hack.
 
 Key files:
 
@@ -267,6 +280,6 @@ describes its purpose and role within the larger system.
 ## Contacts
 
 The main SQLite webpage is [http://www.sqlite.org/](http://www.sqlite.org/)
-with geographically distributed backup servers at
+with geographically distributed backups at
 [http://www2.sqlite.org/](http://www2.sqlite.org) and
 [http://www3.sqlite.org/](http://www3.sqlite.org).