Index: index.html
===================================================================
--- index.html	(revision 5702)
+++ index.html	(revision 5703)
@@ -10,7 +10,7 @@
 	<li> ... this led to a variety of configuration formats; using one format not always because it was better suited for the task, but for historical reasons
 	<li> ... this also led to a collection of config files - again not always split by boundaries of settings, but often by arbitrary boundaries of code
 	<li> the old system didn't support lists or arrays well
-	<li> it didn't have a coherent concept of how settings from different <a href="sources.html"> sources </a> would override eachother
+	<li> it didn't have a coherent concept of how settings from different <a href="sources.html"> sources </a> would override each other
 	<li> ... this resulted in the rigid structure that most of the settings could come from only one place (e.g. if it's an user setting, the design won't be able to override it)
 </ul>
 
@@ -17,14 +17,14 @@
 <H2> What the new system offers </H2>
 <ul>
 	<li> unified format: <a href="http://repo.hu/projects/lihata"> lihata </a> ...
-	<li> ... more future proof: generic markup language - easier to extend wihtout having to worry about breaking the syntax
-	<li> ... the configuration is represented in a tree, groupped by the nature of settings
+	<li> ... more future proof: generic markup language - easier to extend without having to worry about breaking the syntax
+	<li> ... the configuration is represented in a tree, grouped by the nature of settings
 	<li> ... there are <a href="lists.html">arrays and lists</a>
 	<li> ... a config file can overwrite a list or <a href="lists.html">prepend/append</a> to it (e.g. design-level config prepending an extra library path keeping system set paths as well)
 	<li> there are different <a href="sources.html"> sources </a> of configuration, e.g. system-wise, user-wise, project-wise, etc.
-	<li> the user has the power to change default config <a href="prio.html">priorty per setting</a>; e.g. normally design config overrides user config, but it's possible to mark a setting from user config so strong that it overrides even the setting read from the .pcb file
+	<li> the user has the power to change default config <a href="prio.html">priority per setting</a>; e.g. normally design config overrides user config, but it's possible to mark a setting from user config so strong that it overrides even the setting read from the .pcb file
 	<li> the way settings are stored is flexible and extensible so that a plugin can define their subtree of settings
-	<li> ... since the API even makes it easier to access such settings (vs. parsing your own config file), plugins will tend to use the unified config format/system instead of inventing teir own
+	<li> ... since the API even makes it easier to access such settings (vs. parsing your own config file), plugins will tend to use the unified config format/system instead of inventing their own
 	<li> ... the GUI (gtk's preferences dialog) thus can automatically handle the new settings
 	<li> ... plugins don't have to implement actions to set/toggle/query their settings for the menu system, there are generic config set/toggle/query actions the menu config can use
 	<li> ... plugins also get the multi-source, <a href="prio.html">priority-based config mechanism</a>
Index: index_user.html
===================================================================
--- index_user.html	(revision 5702)
+++ index_user.html	(revision 5703)
@@ -18,7 +18,7 @@
 carry out their tasks.
 <p>
 Config settings are imported from multiple sources: from different files,
-from environment vareiables, from command line arguments, from the .pcb
+from environment variables, from command line arguments, from the .pcb
 files on load. Any source can define any part of the <i>config tree</i>.
 When the configuration is processed, each source is read into a temporary
 tree and then all the temporary trees are merged into the final
@@ -34,7 +34,7 @@
 <a href="sources.html">purpose of the source</a>. The next
 step is following the red arrows in two steps:
 <ul>
-	<li> first merge all the role treesinto a flat list; this determines the value of each setting;
+	<li> first merge all the role trees into a flat list; this determines the value of each setting;
 	<li> then dispatch the values to the right component of the code.
 </ul>
 Some components may change some of the settings run-time. The trivial example
@@ -43,7 +43,7 @@
 to the design role tree directly, from where the new value is again merged
 and dispatched along the red arrows. Changes in the design role are saved
 with the .pcb file (thus the bidirectional black arrow between the source and
-the in-memory tree for the design role). Occassionally the user wants to
+the in-memory tree for the design role). Occasionally the user wants to
 save parts of the setting as a <a href="sources.html"> project setting or
 as an user setting</a> - in this case, along the dashed blue lines, the
 corresponding project or user roles are modified. This again results in updating
@@ -60,7 +60,7 @@
 sets a given item).
 
 <h3> overlaps </h3>
-Each setting in each source has a <a href="prio.html">prioirty.</a> The
+Each setting in each source has a <a href="prio.html">priority.</a> The
 priority can be defined in the source, or if it is not defined, each source
 inherits a fallback default priority. The fallback is designed to provide
 the intuitive order: cli &gt; design &gt; project &gt; user &gt; system.
@@ -79,7 +79,7 @@
 values. They are described in a lihata list item ("li:") in the config
 files and are generally called lists in this document. How lists
 are merged is controlled by the merging <i>policy</i>, which can be
-in each source, just like the prioirty is set. Check out the
+in each source, just like the priority is set. Check out the
 <a href="lists.html">list merging section</a> for more details.
 
 <h3> blind spots </h3>
Index: prio.html
===================================================================
--- prio.html	(revision 5702)
+++ prio.html	(revision 5703)
@@ -15,7 +15,7 @@
 is a tie, role decides: the role closer to the CLI is stronger.
 <p>
 For <a href="lists.html">lists</a> and arrays, priority determines the
-order of merge, which changes the order of itmes in the final list as
+order of merge, which changes the order of items in the final list as
 config roots prepend and append items.
 
 
Index: scalars.html
===================================================================
--- scalars.html	(revision 5702)
+++ scalars.html	(revision 5703)
@@ -26,7 +26,7 @@
 	<tr><td> 2.   <td> apply <i>user</i>   <td> A       <td> "not defined" doesn't mean "empty", so the list is not deleted - no change
 	<tr><td> 3.   <td> apply <i>project</i><td> Q       <td> replace the original output because of the overwrite policy
 </table>
-<p>Example scenario: system default overriden by a project setting.
+<p>Example scenario: system default overridden by a project setting.
 
 <h3> user-forced value </h3>
 Config sources append:
@@ -48,7 +48,7 @@
 <p>Example scenario: user preference enforced: even if the project file would use
 'Q' for the given setting, the user prefers 'E'. This affects runtime
 (the value of the setting after the merge, in other words how pcb-rnd works),
-but does nto change the project configuration. This allows the given user to
+but does not change the project configuration. This allows the given user to
 always use 'E' for the given setting while lets other users working on the
 same project use the value set in the project file.
 
Index: sources.html
===================================================================
--- sources.html	(revision 5702)
+++ sources.html	(revision 5703)
@@ -19,7 +19,7 @@
     <td> 200
     <td> /usr/share/pcb-rnd/pcb-conf.lht
     <td> recommended
-    <td> should hold system and installation specific settigns, e.g. path to the system-wise installed footprint library
+    <td> should hold system and installation specific settings, e.g. path to the system-wise installed footprint library
 
 <tr><td> default.pcb
     <td> 300
@@ -36,12 +36,12 @@
 <tr><td> environment
     <td> 500
     <td> environment variables (TODO)
-    <td> occassional
+    <td> occasional
     <td> inject the same (temporary) settings in multiple pcb-rnd sessions without having to change config files
 
 <tr><td> project
     <td> 600
-    <td> projdect.lht in the project directory
+    <td> project.lht in the project directory
     <td> optional
     <td> local project settings - useful for large projects with multiple design (.pcb) files
 
@@ -54,7 +54,7 @@
 <tr><td> cli
     <td> 800
     <td> command line argument
-    <td> occassional
+    <td> occasional
     <td> inject/change a setting for a single session; useful in batch/automated processing
 </table>
 
@@ -63,7 +63,7 @@
 representation. If a setting is specified in multiple sources, the one
 with the higher priority wins, except for lists where it is also possible
 to prepend/append items. Default priorities are designed to result
-precedence in an intuitive way (e.g. design settigns overwrite user settings).
+precedence in an intuitive way (e.g. design settings overwrite user settings).
 However, <a href="prio.html">priority can be changed</a> per setting, resulting
 in weak settings ("use this value if it was not already set") or strong settings
 ("I always want to use mincut, so I enable it from my user's config with high
Index: syntax.html
===================================================================
--- syntax.html	(revision 5702)
+++ syntax.html	(revision 5703)
@@ -3,11 +3,11 @@
 <H1> The new config system in pcb-rnd </H1>
 <H2> Config file syntax </H2>
 
-The config file sytnax is <a href="http://repo.hu/projects/lihata">lihata</a>.
+The config file syntax is <a href="http://repo.hu/projects/lihata">lihata</a>.
 Most users don't need to understand most of the syntax, just follow the
 patterns seen in the examples. A few thumb of rules:
 <ul>
-	<li> srtuctural nodes usually start with a ha: or li: prefix; which one needs to be used is pretty much tied to the node name; thus casual users don't need to care about what they are for, just remember them as part of the name
+	<li> structural nodes usually start with a ha: or li: prefix; which one needs to be used is pretty much tied to the node name; thus casual users don't need to care about what they are for, just remember them as part of the name
 	<li> non-structural nodes are usually given in the form of name = value; use braces around the value if it contains any non-alphanumeric, non-whitespace character
 	<li> list and array members should better be braced
 	<li> list and array separator should be semicolon (not comma)
@@ -22,7 +22,7 @@
 <p>
 Each config root is a partial description of the
 <a href=index_user.html"> config tree </a> (which is the logical
-confgiuration of all possible settings). Config roots have a policy and
+configuration of all possible settings). Config roots have a policy and
 a <a href="prio.html">priority</a> attached. This is done in the name
 of the config root, which must be of the form of <i>policy-priority</i>,
 e.g. "overwrite-300" or "append-125". The priority part (with the dash)
@@ -31,7 +31,7 @@
 <p>
 Under the config root, a tree of sections (hashes) and setting values
 (text nodes) are built. These structures and values are in 1:1 
-correspondance with <a href="groups.html">the config tree</a>. Excess
+correspondence with <a href="groups.html">the config tree</a>. Excess
 (unknown) keys are considered a warning (except in the plugin/ and
 utils/ subtrees). Missing keys or missing subtrees is normal because a config
 root can be partial.
Index: tree/editor_selection.html
===================================================================
--- tree/editor_selection.html	(revision 5702)
+++ tree/editor_selection.html	(revision 5703)
@@ -3,6 +3,6 @@
 <h2>subtree: editor/selection</h2>
 <table border=1>
 <tr><th>node name <th> type <td> flags <td> description
-<tr><td> disable_negative <td><a href="CFN_BOOLEAN.html"> boolean </a><td> 0 <td> selection box behaviour: diable the negative-direction selection - any selection box will select only what's fully within the box
+<tr><td> disable_negative <td><a href="CFN_BOOLEAN.html"> boolean </a><td> 0 <td> selection box behaviour: disable the negative-direction selection - any selection box will select only what's fully within the box
 <tr><td> symmetric_negative <td><a href="CFN_BOOLEAN.html"> boolean </a><td> 0 <td> selection box behaviour: when set, the selection direction is considered negative only if the box has negative size in the X direction
 </table></body></html>
Index: tree/rc.html
===================================================================
--- tree/rc.html	(revision 5702)
+++ tree/rc.html	(revision 5703)
@@ -6,8 +6,8 @@
 <tr><td> verbose <td><a href="CFN_INTEGER.html"> integer </a><td> 0 <td> <verbose>
 <tr><td> quiet <td><a href="CFN_INTEGER.html"> integer </a><td> 0 <td> print only errors on stderr
 <tr><td> backup_interval <td><a href="CFN_INTEGER.html"> integer </a><td> 0 <td> time between two backups in seconds
-<tr><td> font_command <td><a href="CFN_STRING.html"> string </a><td> 0 <td> file name template; if not empty, run this command and read its outout for loading the font; %f is the file name
-<tr><td> file_command <td><a href="CFN_STRING.html"> string </a><td> 0 <td> file name template; if not empty, run this command and read its outout for loading a pcb file; %f is the file name, %p is the conf setting rc.file_path
+<tr><td> font_command <td><a href="CFN_STRING.html"> string </a><td> 0 <td> file name template; if not empty, run this command and read its output for loading the font; %f is the file name
+<tr><td> file_command <td><a href="CFN_STRING.html"> string </a><td> 0 <td> file name template; if not empty, run this command and read its output for loading a pcb file; %f is the file name, %p is the conf setting rc.file_path
 <tr><td> file_path <td><a href="CFN_STRING.html"> string </a><td> 0 <td> <file_path>
 <tr><td> library_shell <td><a href="CFN_STRING.html"> string </a><td> 0 <td> <library_shell>
 <tr><td> library_search_paths <td><a href="CFN_LIST.html"> list </a><td> 0 <td> <library_search_paths>
@@ -20,7 +20,7 @@
 <tr><td> script_filename <td><a href="CFN_STRING.html"> string </a><td> 0 <td> PCB Actions script to execute on startup
 <tr><td> action_string <td><a href="CFN_STRING.html"> string </a><td> 0 <td> PCB Actions string to execute on startup
 <tr><td> rat_path <td><a href="CFN_STRING.html"> string </a><td> 0 <td> <rat_path>
-<tr><td> rat_command <td><a href="CFN_STRING.html"> string </a><td> 0 <td> file name template; if not empty, run this command and read its outout for loading a rats; %f is the file name, %p is the rc.rat_path conf setting
+<tr><td> rat_command <td><a href="CFN_STRING.html"> string </a><td> 0 <td> file name template; if not empty, run this command and read its output for loading a rats; %f is the file name, %p is the rc.rat_path conf setting
 <tr><td> preferred_gui <td><a href="CFN_LIST.html"> list </a><td> 0 <td> if set, try GUI HIDs in this order when no GUI is explicitly selected
 <tr><td> have_regex <td><a href="CFN_BOOLEAN.html"> boolean </a><td> 0 <td> whether we have regex compiled in
 </table></body></html>