Run the docs through a spell checker. I usually use an editor that doesn't have one.

9 files changed, 17 insertions, 17 deletions

diff --git a/docs/ClientHamr/README.GuiLua b/docs/ClientHamr/README.GuiLua
index f60d7b2..72f13f3 100644
--- a/docs/ClientHamr/README.GuiLua
+++ b/docs/ClientHamr/README.GuiLua
@@ -97,7 +97,7 @@ something else), then unmarshal the result before sending it back to
 Lua.
 
 The second alternative, which the host app must REALLY request, is for
-the host app to say "I'm REALLY going out of my way to be threadsafe,
+the host app to say "I'm REALLY going out of my way to be thread safe,
 just call me direct".  No edje wrapper function, BUT the host app still
 has to use edje to register this function.
 
@@ -568,8 +568,8 @@ Windows with widgets relative to each other.
 Manual association of widgets to methods.
 Can include tool tip string, enabled, visible, hover cursor, bounding rectangle?, mouse opaque?, tab groups, font (name, size, style, and alignment).
     More stuff, typically hidden in the OO somewhere.  sigh
-Generally uses fixed image and colour names, which skins overide.
-Skins can also overide the XML files.
+Generally uses fixed image and colour names, which skins override.
+Skins can also override the XML files.
 Translations provide override XML files that need only override the text bits.
 
 
diff --git a/docs/ClientHamr/README.woMan b/docs/ClientHamr/README.woMan
index 1b3bbe0..990f9c5 100644
--- a/docs/ClientHamr/README.woMan
+++ b/docs/ClientHamr/README.woMan
@@ -25,7 +25,7 @@ viewer is not TPVP (Third Party Viewer Policy, an LL thing) compliant,
 and LL are just more anal than the rest of the universe.
 
 NOTE: since I started this, LL in their *cough* infinite wisdom *cough*,
-decided that support of OpenSIm was a Really Bad Thing, so their viewers
+decided that support of OpenSim was a Really Bad Thing, so their viewers
 are no longer capable of dealing with other grids.  LL have even gone as
 far as try to get other viewers to not support other grids.  As far as
 woMan is concerned, this just means that LL viewers, and viewers that
diff --git a/docs/ClientHamr/ScriptEditor.txt b/docs/ClientHamr/ScriptEditor.txt
index 357793a..28cb6a3 100644
--- a/docs/ClientHamr/ScriptEditor.txt
+++ b/docs/ClientHamr/ScriptEditor.txt
@@ -22,5 +22,5 @@ the command finishes.  Naturally that command could be "vi script.lsl",
 
 Toybox and terminology works under cygwin and Mac OS X.
 
-Rob pulls his finger out and starts putting my editting stuff in toybox
+Rob pulls his finger out and starts putting my editing stuff in toybox
 so I can progress with this.
diff --git a/docs/README.Bookie b/docs/README.Bookie
index 1a49f27..bec4b19 100644
--- a/docs/README.Bookie
+++ b/docs/README.Bookie
@@ -28,6 +28,6 @@ versions of the libraries needed in that.  If not found, it could invoke
 an OS specific method of installing a suitable library.  If that fails,
 it can download a SledjHamr specific version into the SledjHamr
 installed directory.  So it tries to do the right thing first, and
-gradually fallsback to doing the wrong thing like LL does.
+gradually falls back to doing the wrong thing like LL does.
 
 That's the theory, in practice, gonna be a pain.
diff --git a/docs/README.LuaSL b/docs/README.LuaSL
index 69bb45c..ed2ffdd 100644
--- a/docs/README.LuaSL
+++ b/docs/README.LuaSL
@@ -1,7 +1,7 @@
 Refer to - http://www.infinitegrid.org/drupal/content/LuaSL_New_scripting_engine
 
 LuaSL is a Lua based LSL scripting engine that will aim for LSL
-compatability first, then adding Lua extensions.  It aims to replace the
+compatibility first, then adding Lua extensions.  It aims to replace the
 woeful XEngine from OpenSim, and at a later stage, be the basis for a
 client side scripting engine.
 
@@ -38,7 +38,7 @@ future.
 
 THIS IS WHERE WE ARE RIGHT NOW.
 
-Should implement embedded Lua somehow.  Probaly the best thing to do is
+Should implement embedded Lua somehow.  Probably the best thing to do is
 to have comments like -
 
 //Lua: local t = {1, 3, 42, x='something', 'something else}
@@ -55,7 +55,7 @@ Incoming commands invoke LSL events via the LuaSL state metatable.  LL
 and OS functions that impact the world will be converted to nails
 commands sent to the command pump.
 
-Initialy, since this is the first thing being written, a nails command
+Initially, since this is the first thing being written, a nails command
 pump client needs to be installed into OpenSim's C# stuff.  Though it
 might be possible to talk directly to ROBUST instead.  Think I'll try
 the ROBUST route, see how far I can get.  That's the general principle
diff --git a/docs/README.REST b/docs/README.REST
index 2981827..0d773f8 100644
--- a/docs/README.REST
+++ b/docs/README.REST
@@ -1,2 +1,2 @@
-REST is probaly good to apply to the web server part.  Alice wants JSON
+REST is probably good to apply to the web server part.  Alice wants JSON
 to, but see nails.
diff --git a/docs/The_Naminator.txt b/docs/The_Naminator.txt
index 3465d44..8a6a25e 100644
--- a/docs/The_Naminator.txt
+++ b/docs/The_Naminator.txt
@@ -6,7 +6,7 @@ and URLs, so the names have to be munged accordingly.  A further issue
 is that different in world objects can have the same name.  Lots of
 copies of the same thing, or two different things that happen to be
 called the same thing.  No one is gonna individually name each tree in a
-forest, or every lampost in the city.  File names and URLs have to be
+forest, or every lamppost in the city.  File names and URLs have to be
 unique.  The Naminator deals with munging names to deal with these
 issues.  It should generate names that are compatible with a variety of
 operating and file systems, as well as being URL compatible.  This is
diff --git a/docs/love.txt b/docs/love.txt
index e21b18b..d95dc30 100644
--- a/docs/love.txt
+++ b/docs/love.txt
@@ -57,7 +57,7 @@ the major amounts of web infrastructure that already exists and already
 solves most of the problems that currently plague virtual worlds based
 on SL tech.
 
-The down side of separated is that changes might be slower propogating
+The down side of separated is that changes might be slower propagating
 to the web server, and there might be two copies of any given set of
 assets in memory at once.
 
@@ -127,7 +127,7 @@ inspired by git using SHA-1 hashes for content addressable assets.
 SHA-1 hashes are 40 character hex codes representing 160 bit numbers
 that are calculated based on the content.  So the same content will give
 the same SHA-1 hash.  Git has proved that you only need the first digits
-of the SHA-1 hash to ensure uniqueness, so it's feasable to use only the
+of the SHA-1 hash to ensure uniqueness, so it's feasible to use only the
 first 128 bits of SHA-1 hashes to squeeze it into a UUID for the
 purposes of uniquely identifying assets.  Precisely what git does.  This
 means it could be backwards compatible with LL's use of UUIDs.
diff --git a/docs/portals.txt b/docs/portals.txt
index c2ba0a1..d54c235 100644
--- a/docs/portals.txt
+++ b/docs/portals.txt
@@ -3,7 +3,7 @@ SledjHamrs killer feature, or one of them.
 A major reason for SledjHamr is to break down the garden walls.  We do
 this by allowing free travel between peoples virtual worlds.  In OpenSim
 this is done by HyperGrid, which is clunky and hard to use.  Second Life
-deliberatly has no such system.  Even worse, it's hard convincing people
+deliberately has no such system.  Even worse, it's hard convincing people
 in SL to visit your grid, coz it's all very hard, again due to
 deliberate policy decisions by LL.  LL knows their content is the key to
 their business, even though almost all of it was created by the users,
@@ -31,7 +31,7 @@ using OpenSim and its HyperGrid system.  Later it would be SledjHamr
 style worlds as well.
 
 A portal would be like Cobalt style portals, you can see the destination
-in real time, and step through it to go there.  They can be permenant,
+in real time, and step through it to go there.  They can be permanent,
 or temporary.  You can carry them in your inventory, they could just be
 normal scripted in world objects.
 
@@ -46,7 +46,7 @@ rez it anywhere.  Or you could rez this portal object in the world you
 are in.  Either way, once the portal is in a world, it connects to your
 home world, showing a view of your front gate, maybe including your
 lovely garden in your front yard.  The portal connects to the "front
-gate" of your homeworld.
+gate" of your home world.
 
 Any one on your home worlds access list can step through this portal to
 get to your home world.  Simple to use, no figuring out HyperGate URLs
@@ -59,7 +59,7 @@ Portals rezzed in world could be temporary, and vanish after who ever
 you invited to come stepped through it.  Or time out several minutes
 later so as not to clutter the universe with left over portals.  Or
 deleted by the owner / managers of the world you left them, or deleted
-yourself from your own world.  Portals could be permenant.  Say you
+yourself from your own world.  Portals could be permanent.  Say you
 found a larger world that you and the owner decide you wish to be a part
 of.  Portals could be left on both worlds linking them.  The "portal"
 could just be reconfiguring each world to locate the other world near