Index: trunk/doc/developer/c89.html
===================================================================
--- trunk/doc/developer/c89.html	(revision 5614)
+++ trunk/doc/developer/c89.html	(revision 5615)
@@ -6,9 +6,9 @@
 written in C99. It's not yet decided whether the code will be C89 or C99
 long term. If it'll be C89, the C99 parts will be rewritten. If it'll be
 C99, new code can use C99 features freely. Until the decision, keep
-new code C89. Especlially watch out for these:
+new code C89. Especially watch out for these:
 <ul>
-	<li> commengt: always use /* */, never //
+	<li> comment: always use /* */, never //
 	<li> don't mix variable declaration with code - open a new {} block, which will also scope your new variables, or better yet, split up the function into smaller, static functions, the compiler will inline them anyway
 	<li> try to avoid vararg macros, use vararg functions instead
 </ul>
Index: trunk/doc/developer/ddrc/proposal1.txt
===================================================================
--- trunk/doc/developer/ddrc/proposal1.txt	(revision 5614)
+++ trunk/doc/developer/ddrc/proposal1.txt	(revision 5615)
@@ -146,7 +146,7 @@
 
 P70 list(LISTNAME)
     Within an expression, a reference to a list may become an iterator and
-    refer to a single object. In case the expression needs the listm the
+    refer to a single object. In case the expression needs the list, the
     list() function protects LISTNAME from becoming an iterator. For
     example llen(list(@)) is the number of all objects the design consists.
 
Index: trunk/doc/developer/ddrc/requirements.txt
===================================================================
--- trunk/doc/developer/ddrc/requirements.txt	(revision 5614)
+++ trunk/doc/developer/ddrc/requirements.txt	(revision 5615)
@@ -12,7 +12,7 @@
 		- detect minimal width (high current)
 		- detect poly hairpin
 		- number and length of stubs (hight freq)
-		- "via cage": a given network needs to be sorrounded by a set of gnd vias
+		- "via cage": a given network needs to be surrounded by a set of gnd vias
 	- network related copper checks
 		- matched length lines (e.g. fast dram bus)
 		- balanced transmission line (distance between the tracks)
Index: trunk/doc/developer/mods3/index.html
===================================================================
--- trunk/doc/developer/mods3/index.html	(revision 5614)
+++ trunk/doc/developer/mods3/index.html	(revision 5615)
@@ -25,9 +25,9 @@
 <p>
 I believe such modularization has benefits on multiple levels:
 <ul>
-	<li> it is possible to compiler smaller, potentially faster executables by omitting features the specific user would never use anyway
+	<li> it is possible to compile smaller, potentially faster executables by omitting features the specific user would never use anyway
 	<li> in a distribution dynamic-link plugins can be distributed as separate packages providing the user with the option to decide what features to install
-	<li> such plugins have to have some sort of APIs if they want to reference eachother or if the code needs to reference them; such an API may not (and often did not) exist when the code is part of the core
+	<li> such plugins have to have some sort of APIs if they want to reference each other or if the code needs to reference them; such an API may not (and often did not) exist when the code is part of the core
 </ul>
 
 <H2> Progress in charts </H2>
Index: trunk/doc/developer/mods3/pre.html
===================================================================
--- trunk/doc/developer/mods3/pre.html	(revision 5614)
+++ trunk/doc/developer/mods3/pre.html	(revision 5615)
@@ -25,9 +25,9 @@
 <p>
 I believe such modularization has benefits on multiple levels:
 <ul>
-	<li> it is possible to compiler smaller, potentially faster executables by omitting features the specific user would never use anyway
+	<li> it is possible to compile smaller, potentially faster executables by omitting features the specific user would never use anyway
 	<li> in a distribution dynamic-link plugins can be distributed as separate packages providing the user with the option to decide what features to install
-	<li> such plugins have to have some sort of APIs if they want to reference eachother or if the code needs to reference them; such an API may not (and often did not) exist when the code is part of the core
+	<li> such plugins have to have some sort of APIs if they want to reference each other or if the code needs to reference them; such an API may not (and often did not) exist when the code is part of the core
 </ul>
 
 <H2> Progress in charts </H2>
Index: trunk/doc/developer/obj_func_naming.txt
===================================================================
--- trunk/doc/developer/obj_func_naming.txt	(revision 5614)
+++ trunk/doc/developer/obj_func_naming.txt	(revision 5615)
@@ -12,7 +12,7 @@
 
 	pcb_*_new_*():
 		Same as pcb_*_new(), but may do clever things so the object created may
-		not be 1:1 what was reqested or may not even be a new object (e.g.
+		not be 1:1 what was requested or may not even be a new object (e.g.
 		overlapping line merging)
 
 	pcb_element_*_new():
@@ -66,7 +66,7 @@
 		state, e.g. "change side" would move the object to the currently viewed
 		side.
 
-Trasformations:
+Transformations:
 	pcb_*_move():
 		move the object within its parent (x;y); it's often implemented as a
 		macro
Index: trunk/doc/developer/packaging.txt
===================================================================
--- trunk/doc/developer/packaging.txt	(revision 5614)
+++ trunk/doc/developer/packaging.txt	(revision 5615)
@@ -48,7 +48,7 @@
 
 3. typical ./configure options - scconfig vs. auto*
 
-./configurfe --prefix works as expected. DESTDIR is called install_root.
+./configure --prefix works as expected. DESTDIR is called install_root.
 
 Typical commands for configuring pcb-rnd for packaging would be:
 
Index: trunk/doc/devlog/20160409/legend.txt
===================================================================
--- trunk/doc/devlog/20160409/legend.txt	(revision 5614)
+++ trunk/doc/devlog/20160409/legend.txt	(revision 5615)
@@ -18,11 +18,11 @@
 b. yes, sometimes, rarely (e.g. I once had to do something repeatedly and 
 added a key binding for that)
 c. never, I know where I'd perform the changes if I ever needed 
-them but defalts are good enough for now
+them but defaults are good enough for now
 d. never, I don't know what a menu resource file is
 
 
-4. If you do not costumize your menu resource file, it's because (select 
+4. If you do not customize your menu resource file, it's because (select 
 zero or more):
 a. I don't need to
 b. the file is too long
@@ -31,7 +31,7 @@
 e. I don't like the idea of editing text config files, I want a GUI for 
 this
 f. I don't want to diverge from the default settings (e.g. because of 
-potetial hassle at a later upgrade)
+potential hassle at a later upgrade)
 
 
 5. Do you miss multi-key sequences from the GTK hid? (select one)
Index: trunk/doc/plan.txt
===================================================================
--- trunk/doc/plan.txt	(revision 5614)
+++ trunk/doc/plan.txt	(revision 5615)
@@ -66,11 +66,11 @@
 _styleguide notes:_
 urls all lowercased (eg. GTK becomes gtk)
 pronouns: write to avoid pronouns, use user/developer, use she
-organization:  hierarchial with lots of links for people who have tunneled deep?
-naviagation: don't add navigation in page, rely on browser navs
+organization:  hierarchical with lots of links for people who have tunneled deep?
+navigation: don't add navigation in page, rely on browser navs
 html strict:  use standard html 1.0 
 css:  use css for looks without content modification 
 assets: generate assets (use dot, etc), assume make and same system is able to build pcb-rnd
 tables: use zebra styling for ease of reading 
-deps/requirements for pcb-rnd itself (we need an appendix table to live createthe actions list)
+deps/requirements for pcb-rnd itself (we need an appendix table to live create the actions list)
 naming sections: despite lowercasing urls, keep naming concise so links have names that lead to sections with same names
Index: trunk/doc/wishlist.txt
===================================================================
--- trunk/doc/wishlist.txt	(revision 5614)
+++ trunk/doc/wishlist.txt	(revision 5615)
@@ -21,7 +21,7 @@
 				- everything should have an attribute hash -> W6
 				- footprints should have optional attachments (e.g. 3d models) -> W5
 		This helps us testing out the persistent-lihata idea that'd be
-		later used in chscem from the start -> W1
+		later used in cschem from the start -> W1
 		This is also needed for more generic footprint implementation -> W3
 
 	B. visible attribute support
Index: trunk/src_plugins/hid_gtk/gui-config.c
===================================================================
--- trunk/src_plugins/hid_gtk/gui-config.c	(revision 5614)
+++ trunk/src_plugins/hid_gtk/gui-config.c	(revision 5615)
@@ -2781,7 +2781,7 @@
 	/* build the tree */
 	model = gtk_tree_store_new(N_CONFIG_COLUMNS, G_TYPE_STRING, G_TYPE_INT, G_TYPE_POINTER, G_TYPE_POINTER);
 
-	config_tree_sect(model, NULL, &user_pov,   _("User PoV"),   _("\n<b>User PoV</b>\nA subset of configuration settings regroupped,\npresented in the User's Point of View."));
+	config_tree_sect(model, NULL, &user_pov,   _("User PoV"),   _("\n<b>User PoV</b>\nA subset of configuration settings regrouped,\npresented in the User's Point of View."));
 	config_tree_sect(model, NULL, &config_pov, _("Config PoV"), _("\n<b>Config PoV</b>\nAccess all configuration fields presented in\na tree that matches the configuration\nfile (lht) structure."));
 
 	config_tree_leaf(model, &user_pov, _("General"), config_general_tab_create);