X-Git-Url: https://git.sur5r.net/?a=blobdiff_plain;f=docs%2Fuserguide;h=4bfcdb6b980e5a2009bdc6f61541054c6a7b00e1;hb=ffc7ea8c500a2360bcbe95ea2ad7939e98be31fc;hp=9c601e8869167da2385665ba66a1d57e782393f6;hpb=4cba9fcbdab1487459014dbf8882f5f34e61435e;p=i3%2Fi3

diff --git a/docs/userguide b/docs/userguide
index 9c601e88..4bfcdb6b 100644
--- a/docs/userguide
+++ b/docs/userguide
@@ -245,9 +245,11 @@ you open a new terminal, it will open below the current one.
 
 So, how can you open a new terminal window to the *right* of the current one?
 The solution is to use +focus parent+, which will focus the +Parent Container+ of
-the current +Container+. In this case, you would focus the +Vertical Split
-Container+ which is *inside* the horizontally oriented workspace. Thus, now new
-windows will be opened to the right of the +Vertical Split Container+:
+the current +Container+. In default configuration, use +$mod+a+ to navigate one 
++Container+ up the tree (you can repeat this multiple times until you get to the
++Workspace Container+). In this case, you would focus the +Vertical Split Container+
+which is *inside* the horizontally oriented workspace. Thus, now new windows will be
+opened to the right of the +Vertical Split Container+:
 
 image::tree-shot3.png["shot3",title="Focus parent, then open new terminal"]
 
@@ -755,14 +757,23 @@ set_from_resource $black i3wm.color0 #000000
 
 To automatically make a specific window show up on a specific workspace, you
 can use an *assignment*. You can match windows by using any criteria,
-see <<command_criteria>>. It is recommended that you match on window classes
-(and instances, when appropriate) instead of window titles whenever possible
-because some applications first create their window, and then worry about
-setting the correct title. Firefox with Vimperator comes to mind. The window
-starts up being named Firefox, and only when Vimperator is loaded does the
-title change. As i3 will get the title as soon as the application maps the
-window (mapping means actually displaying it on the screen), you’d need to have
-to match on 'Firefox' in this case.
+see <<command_criteria>>. The difference between +assign+ and
++for_window <criteria> move to workspace+ is that the former will only be
+executed when the application maps the window (mapping means actually displaying
+it on the screen) but the latter will be executed whenever a window changes its
+properties to something that matches the specified criteria.
+
+Thus, it is recommended that you match on window classes (and instances, when
+appropriate) instead of window titles whenever possible because some
+applications first create their window, and then worry about setting the correct
+title. Firefox with Vimperator comes to mind. The window starts up being named
+Firefox, and only when Vimperator is loaded does the title change. As i3 will
+get the title as soon as the application maps the window, you’d need to have to
+match on 'Firefox' in this case.
+Another known issue is with Spotify, which doesn't set the class hints when
+mapping the window, meaning you'll have to use a +for_window+ rule to assign
+Spotify to a specific workspace.
+Finally, using +assign [tiling]+ and +assign [floating]+ is not supported.
 
 You can also assign a window to show up on a specific output. You can use RandR
 names such as +VGA1+ or names relative to the output with the currently focused
@@ -995,7 +1006,7 @@ ipc-socket ~/.i3/i3-ipc.sock
 ----------------------------
 
 You can then use the +i3-msg+ application to perform any command listed in
-the next section.
+<<list_of_commands>>.
 
 === Focus follows mouse
 
@@ -1716,6 +1727,7 @@ bar {
 }
 --------------------------------------
 
+[[list_of_commands]]
 == List of commands
 
 Commands are what you bind to specific keypresses. You can also issue commands