s/separate/seperate/g (Thanks Donald)

diff --git a/docs/debugging b/docs/debugging
index d52edea9d02301dcc10ac843abb3901d4f46865a..b4bda6709c621dd2e3b3d442effeca92417f6f6d 100644 (file)
--- a/docs/debugging
+++ b/docs/debugging
@@ -14,7 +14,7 @@ debugging and/or need further help, do not hesitate to contact us!
 
 i3 spits out much information onto stdout, if told so. To have a clearly
 defined place where log files will be saved, you should redirect stdout and
-stderr in xsession. While you’re at it, putting each run of i3 in a separate
+stderr in xsession. While you’re at it, putting each run of i3 in a seperate
 log file with date/time in it is a good idea to not get confused about the
 different log files later on.
 

diff --git a/docs/hacking-howto b/docs/hacking-howto
index dff074cbf4bc2a101da7a8e128480d0425dd8aa7..8a778546d18512d4407162773cda652cc33e8775 100644 (file)
--- a/docs/hacking-howto
+++ b/docs/hacking-howto
@@ -216,7 +216,7 @@ screen you are currently on.
 A workspace is identified by its number. Basically, you could think of
 workspaces as different desks in your office, if you like the desktop
 methaphor. They just contain different sets of windows and are completely
-separate of each other. Other window managers also call this ``Virtual
+seperate of each other. Other window managers also call this ``Virtual
 desktops''.
 
 === The layout table
@@ -264,7 +264,7 @@ should be chosen for those:
 == Startup (src/mainx.c, main())
 
  * Establish the xcb connection
- * Check for XKB extension on the separate X connection
+ * Check for XKB extension on the seperate X connection
  * Check for Xinerama screens
  * Grab the keycodes for which bindings exist
  * Manage all existing windows

diff --git a/docs/ipc b/docs/ipc
index 5fcaf62ed721b068826d2453fd31dc3f32c1b07e..c35e9016f941311ed06df040e0dfbd3e9bad3558 100644 (file)
--- a/docs/ipc
+++ b/docs/ipc
@@ -3,7 +3,7 @@ IPC interface (interprocess communication)
 Michael Stapelberg <michael+i3@stapelberg.de>
 March 2010
 
-This document describes how to interface with i3 from a separate process. This
+This document describes how to interface with i3 from a seperate process. This
 is useful for example to remote-control i3 (to write test cases for example) or
 to get various information like the current workspaces to implement an external
 workspace bar.
@@ -241,7 +241,7 @@ situation can happen: You send a GET_WORKSPACES request but you receive a
 "workspace" event before receiving the reply to GET_WORKSPACES. If your
 program does not want to cope which such kinds of race conditions (an
 event based library may not have a problem here), I suggest you create a
-separate connection to receive events.
+seperate connection to receive events.
 
 === Subscribing to events
 

diff --git a/docs/userguide b/docs/userguide
index f3d71fcd239e77616d20b9ebcef85c4594779ee0..7402f64bce95bfa247580d8dc199c625b0badff1 100644 (file)
--- a/docs/userguide
+++ b/docs/userguide
@@ -556,7 +556,7 @@ simple -- it does not provide a way to display custom text and it does not
 offer advanced customization features. This is intended because we do not
 want to duplicate functionality of tools like +dzen2+, +xmobar+ and so on
 (they render bars, we manage windows). Instead, there is an option which will
-turn off the internal bar completely, so that you can use a separate program to
+turn off the internal bar completely, so that you can use a seperate program to
 display it (see +i3-wsbar+, a sample implementation of such a program):
 
 *Syntax*: