Fix spelling mistakes

[i3/i3] / docs / hacking-howto

diff --git a/docs/hacking-howto b/docs/hacking-howto
index 71919e3043435b959d639547239ef5b8f420e620..74a690e7c1ef65d323d5a5f0b03338b3c7b60c79 100644 (file)
--- a/docs/hacking-howto
+++ b/docs/hacking-howto
@@ -117,7 +117,7 @@ containers, searching containers, getting specific properties from containers,
 
 src/config.c::
 Contains all functions handling the configuration file (calling the parser
-(src/cfgparse.y) with the correct path, switching key bindings mode).
+src/config_parser.c) with the correct path, switching key bindings mode).
 
 src/debug.c::
 Contains debugging functions to print unhandled X events.
@@ -187,7 +187,7 @@ cleanup ("flatten") the tree. See also +src/move.c+ for another similar
 function, which was moved into its own file because it is so long.
 
 src/util.c::
-Contains useful functions which are not really dependant on anything.
+Contains useful functions which are not really dependent on anything.
 
 src/window.c::
 Handlers to update X11 window properties like +WM_CLASS+, +_NET_WM_NAME+,
@@ -404,10 +404,14 @@ can reconfigure themselves).
 
 == _NET_WM_STATE
 
-Only the _NET_WM_STATE_FULLSCREEN atom is handled. It calls
-``toggle_fullscreen()'' for the specific client which just configures the
-client to use the whole screen on which it currently is. Also, it is set as
-fullscreen_client for the i3Screen.
+Only the _NET_WM_STATE_FULLSCREEN and _NET_WM_STATE_DEMANDS_ATTENTION atoms
+are handled.
+
+The former calls ``toggle_fullscreen()'' for the specific client which just
+configures the client to use the whole screen on which it currently is.
+Also, it is set as fullscreen_client for the i3Screen.
+
+The latter is used to set, read and display urgency hints.
 
 == WM_NAME
 
@@ -589,7 +593,7 @@ optimize this and call +x_push_node+ on the appropriate con directly.
    itself for the container’s children. This function actually pushes the
    state, see the next paragraph.
 4. If the pointer needs to be warped to a different position (for example when
-   changing focus to a differnt output), it will be warped now.
+   changing focus to a different output), it will be warped now.
 5. The eventmask is restored for all mapped windows.
 6. Window decorations will be rendered by calling +x_deco_recurse+ on the root
    container, which then recursively calls itself for the children.
@@ -629,8 +633,8 @@ unmapped if it should not be visible anymore. +WM_STATE+ will be set to
 +x_draw_decoration+ draws window decorations. It is run for every leaf
 container (representing an actual X11 window) and for every non-leaf container
 which is in a stacked/tabbed container (because stacked/tabbed containers
-display a window decoration for split containers, which at the moment just says
-"another container").
+display a window decoration for split containers, which consists of a representation
+of the child container's names.
 
 Then, parameters are collected to be able to determine whether this decoration
 drawing is actually necessary or was already done. This saves a substantial
@@ -846,7 +850,7 @@ empty.
 Afterwards, +con_focus+ will be called to fix the focus stack and the tree will
 be flattened.
 
-=== Case 3: Moving to non-existant top/bottom
+=== Case 3: Moving to non-existent top/bottom
 
 Like in case 1, the reference layout for this case is a single workspace in
 horizontal orientation with two containers on it. Focus is on the left
@@ -873,7 +877,7 @@ container and the container above/below the current one (on the level of
 Now, +con_focus+ will be called to fix the focus stack and the tree will be
 flattened.
 
-=== Case 4: Moving to existant top/bottom
+=== Case 4: Moving to existent top/bottom
 
 The reference layout for this case is a vertical workspace with two containers.
 The bottom one is a h-split containing two containers (1 and 2). Focus is on
@@ -978,14 +982,16 @@ could have a look at previous reviews and see what the common mistakes are.
 
 === Which branch to use?
 
-Work on i3 generally happens in two branches: “master” and “next”. Since
-“master” is what people get when they check out the git repository, its
-contents are always stable. That is, it contains the source code of the latest
-release, plus any bugfixes that were applied since that release.
+Work on i3 generally happens in two branches: “master” and “next” (the latter
+being the default branch, the one that people get when they check out the git
+repository).
+
+The contents of “master” are always stable. That is, it contains the source code
+of the latest release, plus any bugfixes that were applied since that release.
 
 New features are only found in the “next” branch. Therefore, if you are working
-on a new feature, use the “next” branch. If you are working on a bugfix, use
-the “next” branch, too, but make sure your code also works on “master”.
+on a new feature, use the “next” branch. If you are working on a bugfix, use the
+“next” branch, too, but make sure your code also works on “master”.
 
 == Thought experiments