]> git.sur5r.net Git - i3/i3.github.io/blobdiff - _docs/userguide
docs/buildbot: add pbuilder pkg, use sudoers.d, add umask hint
[i3/i3.github.io] / _docs / userguide
index 4a11cb1b5873451c6f4f948fbac73dc24cc243ec..4145279302eff8368eaf01d353a8add6840d8d49 100644 (file)
@@ -1,7 +1,7 @@
 i3 User’s Guide
 ===============
 Michael Stapelberg <michael+i3@stapelberg.de>
-August 2011
+April 2012
 
 This document contains all the information you need to configure and use the i3
 window manager. If it does not, please contact us on IRC (preferred) or post your
@@ -78,7 +78,7 @@ tabbed::
 The same principle as +stacking+, but the list of windows at the top is only
 a single line which is vertically split.
 
-To switch modes, press +mod+e+ for default, +mod+h+ for stacking and
+To switch modes, press +mod+e+ for default, +mod+s+ for stacking and
 +mod+w+ for tabbed.
 
 image:modes.png[Container modes]
@@ -89,7 +89,7 @@ To display a window in fullscreen mode or to go out of fullscreen mode again,
 press +mod+f+.
 
 There is also a global fullscreen mode in i3 in which the client will span all
-available outputs.
+available outputs (the command is +fullscreen global+).
 
 === Opening other applications
 
@@ -160,7 +160,7 @@ paradigm but can be useful for some corner cases like "Save as" dialog
 windows, or toolbar windows (GIMP or similar). Those windows usually set the
 appropriate hint and are opened in floating mode by default.
 
-You can enable floating mode for a window by pressing +mod+Shift+Space+. By
+You can toggle floating mode for a window by pressing +mod+Shift+Space+. By
 dragging the window’s titlebar with your mouse you can move the window
 around. By grabbing the borders and moving them you can resize the window. You
 can also do that by using the <<floating_modifier>>.
@@ -174,7 +174,7 @@ Floating windows are always on top of tiling windows.
 i3 stores all information about the X11 outputs, workspaces and layout of the
 windows on them in a tree. The root node is the X11 root window, followed by
 the X11 outputs, then dock areas and a content container, then workspaces and
-finally the windows themselve. In previous versions of i3 we had multiple lists
+finally the windows themselves. In previous versions of i3 we had multiple lists
 (of outputs, workspaces) and a table for each workspace. That approach turned
 out to be complicated to use (snapping), understand and implement.
 
@@ -303,7 +303,8 @@ also mix your bindings, though i3 will not protect you from overlapping ones).
 * A keysym (key symbol) is a description for a specific symbol, like "a"
   or "b", but also more strange ones like "underscore" instead of "_". These
   are the ones you use in Xmodmap to remap your keys. To get the current
-  mapping of your keys, use +xmodmap -pke+.
+  mapping of your keys, use +xmodmap -pke+. To interactively enter a key and
+  see what keysym it is configured to, use +xev+.
 
 * Keycodes do not need to have a symbol assigned (handy for custom vendor
   hotkeys on some notebooks) and they will not change their meaning as you
@@ -323,7 +324,7 @@ bindcode [Modifiers+]keycode command
 *Examples*:
 --------------------------------
 # Fullscreen
-bindsym mod+f f
+bindsym mod+f fullscreen
 
 # Restart
 bindsym mod+Shift+r restart
@@ -357,7 +358,8 @@ it to the position you want.
 
 When holding the floating modifier, you can resize a floating window by
 pressing the right mouse button on it and moving around while holding it. If
-you hold the shift button as well, the resize will be proportional.
+you hold the shift button as well, the resize will be proportional (the aspect
+ratio will be preserved).
 
 *Syntax*:
 --------------------------------
@@ -369,6 +371,27 @@ floating_modifier <Modifiers>
 floating_modifier Mod1
 --------------------------------
 
+=== Constraining floating window size
+
+The maximum and minimum dimensions of floating windows can be specified. If
+either dimension of +floating_maximum_size+ is specified as -1, that dimension
+will be unconstrained with respect to its maximum value. If either dimension of
++floating_maximum_size+ is undefined, or specified as 0, i3 will use a default
+value to constrain the maximum size. +floating_minimum_size+ is treated in a
+manner analogous to +floating_maximum_size+.
+
+*Syntax*:
+----------------------------------------
+floating_minimum_size <width> x <height>
+floating_maximum_size <width> x <height>
+----------------------------------------
+
+*Example*:
+--------------------------------------
+floating_minimum_size 75 x 50
+floating_maximum_size -1 x -1
+--------------------------------------
+
 === Orientation for new workspaces
 
 New workspaces get a reasonable default orientation: Wide-screen monitors
@@ -415,7 +438,7 @@ This option determines which border style new windows will have.
 
 *Syntax*:
 ---------------------------------------------
-new_window <normal|1pixel|borderless>
+new_window <normal|1pixel|none>
 ---------------------------------------------
 
 *Example*:
@@ -431,7 +454,7 @@ change their border style, for example.
 
 *Syntax*:
 -----------------------------
-for_window [criteria] command
+for_window <criteria> command
 -----------------------------
 
 *Examples*:
@@ -448,6 +471,8 @@ for_window [class="urxvt"] border 1pixel
 for_window [title="x200: ~/work"] floating enable
 ------------------------------------------------
 
+The valid criteria are the same as those for commands, see <<command_criteria>>.
+
 === Variables
 
 As you learned in the section about keyboard bindings, you will have
@@ -476,37 +501,59 @@ configuration file and run it before starting i3 (for example in your
 
 [[assign_workspace]]
 
-Specific windows can be matched by window class and/or window title. It is
-recommended that you match on window classes 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
+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.
 
-You can prefix or suffix workspaces with a `~` to specify that matching clients
-should be put into floating mode. If you specify only a `~`, the client will
-not be put onto any workspace, but will be set floating on the current one.
-
 *Syntax*:
 ------------------------------------------------------------
-assign ["]window class[/window title]["] [→] [workspace]
+assign <criteria> [→] workspace
 ------------------------------------------------------------
 
 *Examples*:
 ----------------------
-assign urxvt 2
-assign urxvt → 2
-assign urxvt → work
-assign "urxvt" → 2
-assign "urxvt/VIM" → 3
-assign "gecko" → 4
+# Assign URxvt terminals to workspace 2
+assign [class="URxvt"] 2
+
+# Same thing, but more precise (exact match instead of substring)
+assign [class="^URxvt$"] 2
+
+# Same thing, but with a beautiful arrow :)
+assign [class="^URxvt$"] → 2
+
+# Assignment to a named workspace
+assign [class="^URxvt$"] → work
+
+# Start urxvt -name irssi
+assign [class="^URxvt$" instance="^irssi$"] → 3
 ----------------------
 
 Note that the arrow is not required, it just looks good :-). If you decide to
 use it, it has to be a UTF-8 encoded arrow, not `->` or something like that.
 
+To get the class and instance, you can use +xprop+. After clicking on the
+window, you will see the following output:
+
+*xprop*:
+-----------------------------------
+WM_CLASS(STRING) = "irssi", "URxvt"
+-----------------------------------
+
+The first part of the WM_CLASS is the instance ("irssi" in this example), the
+second part is the class ("URxvt" in this example).
+
+Should you have any problems with assignments, make sure to check the i3
+logfile first (see http://i3wm.org/docs/debugging.html). It includes more
+details about the matching process and the window’s actual class, instance and
+title when starting up.
+
 === Automatically starting applications on i3 startup
 
 By using the +exec+ keyword outside a keybinding, you can configure
@@ -517,16 +564,21 @@ keyword. These commands will be run in order.
 
 *Syntax*:
 -------------------
-exec command
-exec_always command
+exec [--no-startup-id] command
+exec_always [--no-startup-id] command
 -------------------
 
 *Examples*:
 --------------------------------
-exec i3status | i3bar -d
+exec chromium
 exec_always ~/my_script.sh
+
+# Execute the terminal emulator urxvt, which is not yet startup-notification aware.
+exec --no-startup-id urxvt
 --------------------------------
 
+The flag --no-startup-id is explained in <<exec>>.
+
 [[workspace_screen]]
 
 === Automatically putting workspaces on specific screens
@@ -539,17 +591,20 @@ the second screen and so on).
 
 *Syntax*:
 ----------------------------------
-workspace <number> output <output>
+workspace <workspace> output <output>
 ----------------------------------
 
 The 'output' is the name of the RandR output you attach your screen to. On a
 laptop, you might have VGA1 and LVDS1 as output names. You can see the
 available outputs by running +xrandr --current+.
 
+If you use named workspaces, they must be quoted:
+
 *Examples*:
 ---------------------------
 workspace 1 output LVDS1
 workspace 5 output VGA1
+workspace "2: vim" output VGA1
 ---------------------------
 
 === Changing colors
@@ -558,7 +613,7 @@ You can change all colors which i3 uses to draw the window decorations.
 
 *Syntax*:
 --------------------------------------------
-colorclass border background text
+colorclass border background text indicator
 --------------------------------------------
 
 Where colorclass can be one of:
@@ -586,20 +641,29 @@ Only clients that do not cover the whole area of this window expose the color
 used to paint it. If you use a color other than black for your terminals, you
 most likely want to set the client background color to the same color as your
 terminal program's background color to avoid black gaps between the rendered
-area of the termianal and the i3 border.
+area of the terminal and the i3 border.
 
 Colors are in HTML hex format (#rrggbb), see the following example:
 
-*Examples*:
---------------------------------------
-# class        border  backgr. text
-client.focused #2F343A #900000 #FFFFFF
---------------------------------------
+*Examples (default colors)*:
+---------------------------------------------------------
+# class                 border  backgr. text    indicator
+client.focused          #4c7899 #285577 #ffffff #2e9ef4
+client.focused_inactive #333333 #5f676a #ffffff #484e50
+client.unfocused        #333333 #222222 #888888 #292d2e
+client.urgent           #2f343a #900000 #ffffff #900000
+---------------------------------------------------------
 
 Note that for the window decorations, the color around the child window is the
 background color, and the border color is only the two thin lines at the top of
 the window.
 
+The indicator color is used for indicating where a new window will be opened.
+For horizontal split containers, the right border will be painted in indicator
+color, for vertical split containers, the bottom border. This only applies to
+single windows within a split container, which are otherwise indistinguishable
+from single windows outside of a split container.
+
 === Interprocess communication
 
 i3 uses unix sockets to provide an IPC interface. This allows third-party
@@ -607,15 +671,19 @@ programs to get information from i3, such as the current workspaces
 (to display a workspace bar), and to control i3.
 
 The IPC socket is enabled by default and will be created in
-+/tmp/i3-%u/ipc-socket.%p+ where +%u+ is your UNIX username and +%p+ is the PID
-of i3.
++/tmp/i3-%u.XXXXXX/ipc-socket.%p+ where +%u+ is your UNIX username, +%p+ is
+the PID of i3 and XXXXXX is a string of random characters from the portable
+filename character set (see mkdtemp(3)).
 
 You can override the default path through the environment-variable +I3SOCK+ or
-by specifying the +ipc-socket+ directive.
+by specifying the +ipc-socket+ directive. This is discouraged, though, since i3
+does the right thing by default. If you decide to change it, it is strongly
+recommended to set this to a location in your home directory so that no other
+user can create that directory.
 
 *Examples*:
 ----------------------------
-ipc-socket /tmp/i3-ipc.sock
+ipc-socket ~/.i3/i3-ipc.sock
 ----------------------------
 
 You can then use the +i3-msg+ application to perform any command listed in
@@ -661,8 +729,444 @@ popup_during_fullscreen <ignore|leave_fullscreen>
 popup_during_fullscreen ignore
 ------------------------------
 
+=== Focus wrapping
+
+When being in a tabbed or stacked container, the first container will be
+focused when you use +focus down+ on the last container -- the focus wraps. If
+however there is another stacked/tabbed container in that direction, focus will
+be set on that container. This is the default behaviour so you can navigate to
+all your windows without having to use +focus parent+.
+
+If you want the focus to *always* wrap and you are aware of using +focus
+parent+ to switch to different containers, you can use the
++force_focus_wrapping+ configuration directive. After enabling it, the focus
+will always wrap.
+
+*Syntax*:
+-----------------------------
+force_focus_wrapping <yes|no>
+-----------------------------
+
+*Example*:
+------------------------
+force_focus_wrapping yes
+------------------------
+
+=== Forcing Xinerama
+
+As explained in-depth in <http://i3wm.org/docs/multi-monitor.html>, some X11
+video drivers (especially the nVidia binary driver) only provide support for
+Xinerama instead of RandR. In such a situation, i3 must be told to use the
+inferior Xinerama API explicitly and therefore don’t provide support for
+reconfiguring your screens on the fly (they are read only once on startup and
+that’s it).
+
+For people who do cannot modify their +~/.xsession+ to add the
++--force-xinerama+ commandline parameter, a configuration option is provided:
+
+*Syntax*:
+-----------------------
+force_xinerama <yes|no>
+-----------------------
+
+*Example*:
+------------------
+force_xinerama yes
+------------------
+
+Also note that your output names are not descriptive (like +HDMI1+) when using
+Xinerama, instead they are counted up, starting at 0: +xinerama-0+, +xinerama-1+, …
+
+=== Automatic back-and-forth when switching to the current workspace
+
+This configuration directive enables automatic +workspace back_and_forth+ (see
+<<back_and_forth>>) when switching to the workspace that is currently focused.
+
+For instance: Assume you are on workspace "1: www" and switch to "2: IM" using
+mod+2 because somebody sent you a message. You don’t need to remember where you
+came from now, you can just press mod+2 again to switch back to "1: www".
+
+*Syntax*:
+--------------------------------------
+workspace_auto_back_and_forth <yes|no>
+--------------------------------------
+
+*Example*:
+---------------------------------
+workspace_auto_back_and_forth yes
+---------------------------------
+
+== Configuring i3bar
+
+The bar at the bottom of your monitor is drawn by a separate process called
+i3bar. Having this part of "the i3 user interface" in a separate process has
+several advantages:
+
+1. It is a modular approach. If you don’t need a workspace bar at all, or if
+   you prefer a different one (dzen2, xmobar, maybe even gnome-panel?), you can
+   just remove the i3bar configuration and start your favorite bar instead.
+2. It follows the UNIX philosophy of "Make each program do one thing well".
+   While i3 manages your windows well, i3bar is good at displaying a bar on
+   each monitor (unless you configure it otherwise).
+3. It leads to two separate, clean codebases. If you want to understand i3, you
+   don’t need to bother with the details of i3bar and vice versa.
+
+That said, i3bar is configured in the same configuration file as i3. This is
+because it is tightly coupled with i3 (in contrary to i3lock or i3status which
+are useful for people using other window managers). Therefore, it makes no
+sense to use a different configuration place when we already have a good
+configuration infrastructure in place.
+
+Configuring your workspace bar starts with opening a +bar+ block. You can have
+multiple bar blocks to use different settings for different outputs (monitors):
+
+*Example*:
+---------------------------
+bar {
+    status_command i3status
+}
+---------------------------
+
+=== i3bar command
+
+By default i3 will just pass +i3bar+ and let your shell handle the execution,
+searching your +$PATH+ for a correct version.
+If you have a different +i3bar+ somewhere or the binary is not in your +$PATH+ you can
+tell i3 what to execute.
+
+The specified command will be passed to +sh -c+, so you can use globbing and
+have to have correct quoting etc.
+
+*Syntax*:
+----------------------
+i3bar_command command
+----------------------
+
+*Example*:
+-------------------------------------------------
+bar {
+    i3bar_command /home/user/bin/i3bar
+}
+-------------------------------------------------
+
+[[status_command]]
+=== Statusline command
+
+i3bar can run a program and display every line of its +stdout+ output on the
+right hand side of the bar. This is useful to display system information like
+your current IP address, battery status or date/time.
+
+The specified command will be passed to +sh -c+, so you can use globbing and
+have to have correct quoting etc.
+
+*Syntax*:
+----------------------
+status_command command
+----------------------
+
+*Example*:
+-------------------------------------------------
+bar {
+    status_command i3status --config ~/.i3status.conf
+}
+-------------------------------------------------
+
+=== Display mode
+
+You can have i3bar either be visible permanently at one edge of the screen
+(+dock+ mode) or make it show up when you press your modifier key (+hide+
+mode). The modifier key can be configured using the +modifier+ option.
+
+The hide mode maximizes screen space that can be used for actual windows. Also,
+i3bar sends the +SIGSTOP+ and +SIGCONT+ signals to the statusline process to
+save battery power.
+
+The default is dock mode; in hide mode, the default modifier is Mod4 (usually
+the windows key).
+
+*Syntax*:
+----------------
+mode <dock|hide>
+modifier <Modifier>
+----------------
+
+*Example*:
+----------------
+bar {
+    mode hide
+    modifier Mod1
+}
+----------------
+
+Available modifiers are Mod1-Mod5, Shift, Control (see +xmodmap(1)+).
+
+[[i3bar_position]]
+=== Position
+
+This option determines in which edge of the screen i3bar should show up.
+
+The default is bottom.
+
+*Syntax*:
+---------------------
+position <top|bottom>
+---------------------
+
+*Example*:
+---------------------
+bar {
+    position top
+}
+---------------------
+
+=== Output(s)
+
+You can restrict i3bar to one or more outputs (monitors). The default is to
+handle all outputs. Restricting the outputs is useful for using different
+options for different outputs by using multiple 'bar' blocks.
+
+To make a particular i3bar instance handle multiple outputs, specify the output
+directive multiple times.
+
+*Syntax*:
+---------------
+output <output>
+---------------
+
+*Example*:
+-------------------------------
+# big monitor: everything
+bar {
+    # The display is connected either via HDMI or via DisplayPort
+    output HDMI2
+    output DP2
+    status_command i3status
+}
+
+# laptop monitor: bright colors and i3status with less modules.
+bar {
+    output LVDS1
+    status_command i3status --config ~/.i3status-small.conf
+    colors {
+        background #000000
+        statusline #ffffff
+    }
+}
+-------------------------------
+
+=== Tray output
+
+i3bar by default provides a system tray area where programs such as
+NetworkManager, VLC, Pidgin, etc. can place little icons.
+
+You can configure on which output (monitor) the icons should be displayed or
+you can turn off the functionality entirely.
+
+*Syntax*:
+-------------------------
+tray_output <none|primary|output>
+-------------------------
+
+*Example*:
+-------------------------
+# disable system tray
+bar {
+    tray_output none
+}
+
+# show tray icons on the primary monitor
+tray_output primary
+
+# show tray icons on the big monitor
+bar {
+    tray_output HDMI2
+}
+-------------------------
+
+Note that you might not have a primary output configured yet. To do so, run:
+-------------------------
+xrandr --output <output> --primary
+-------------------------
+
+=== Font
+
+Specifies the font (again, X core font, not Xft, just like in i3) to be used in
+the bar.
+
+*Syntax*:
+---------------------
+font <font>
+---------------------
+
+*Example*:
+--------------------------------------------------------------
+bar {
+    font -misc-fixed-medium-r-normal--13-120-75-75-C-70-iso10646-1
+}
+--------------------------------------------------------------
+
+=== Workspace buttons
+
+Specifies whether workspace buttons should be shown or not. This is useful if
+you want to display a statusline-only bar containing additional information.
+
+The default is to show workspace buttons.
+
+*Syntax*:
+--------------------------
+workspace_buttons <yes|no>
+--------------------------
+
+*Example*:
+--------------------
+bar {
+    workspace_buttons no
+}
+--------------------
+
+=== Colors
+
+As with i3, colors are in HTML hex format (#rrggbb). The following colors can
+be configured at the moment:
+
+background::
+       Background color of the bar.
+statusline::
+       Text color to be used for the statusline.
+focused_workspace::
+       Border, background and text color for a workspace button when the workspace
+       has focus.
+active_workspace::
+       Border, background and text color for a workspace button when the workspace
+       is active (visible) on some output, but the focus is on another one.
+       You can only tell this apart from the focused workspace when you are
+       using multiple monitors.
+inactive_workspace::
+       Border, background and text color for a workspace button when the workspace
+       does not have focus and is not active (visible) on any output. This
+       will be the case for most workspaces.
+urgent_workspace::
+       Border, background and text color for a workspace button when the workspace
+       window with the urgency hint set.
+
+*Syntax*:
+----------------------------------------
+colors {
+    background <color>
+    statusline <color>
+
+    colorclass <border> <background> <text>
+}
+----------------------------------------
+
+*Example (default colors)*:
+--------------------------------------
+bar {
+    colors {
+        background #000000
+        statusline #ffffff
+
+        focused_workspace  #4c7899 #285577 #ffffff
+        active_workspace   #333333 #5f676a #ffffff
+        inactive_workspace #333333 #222222 #888888
+        urgent_workspace   #2f343a #900000 #ffffff
+    }
+}
+--------------------------------------
+
 == List of commands
 
+Commands are what you bind to specific keypresses. You can also issue commands
+at runtime without pressing a key by using the IPC interface. An easy way to
+do this is to use the +i3-msg+ utility:
+
+*Example*:
+--------------------------
+# execute this on your shell to make the current container borderless
+i3-msg border none
+--------------------------
+
+Commands can be chained by using +;+ (a semicolon). So, to move a window to a
+specific workspace and immediately switch to that workspace, you can configure
+the following keybinding:
+
+*Example*:
+--------------------------------------------------------
+bindsym mod+x move container to workspace 3; workspace 3
+--------------------------------------------------------
+
+[[command_criteria]]
+
+Furthermore, you can change the scope of a command, that is, which containers
+should be affected by that command, by using various criteria. These are
+prefixed in square brackets to every command. If you want to kill all windows
+which have the class Firefox, use:
+
+*Example*:
+------------------------------------
+bindsym mod+x [class="Firefox"] kill
+
+# same thing, but case-insensitive
+bindsym mod+x [class="(?i)firefox"] kill
+------------------------------------
+
+The criteria which are currently implemented are:
+
+class::
+       Compares the window class (the second part of WM_CLASS)
+instance::
+       Compares the window instance (the first part of WM_CLASS)
+window_role::
+       Compares the window role (WM_WINDOW_ROLE).
+id::
+       Compares the X11 window ID, which you can get via +xwininfo+ for example.
+title::
+       Compares the X11 window title (_NET_WM_NAME or WM_NAME as fallback).
+urgent::
+       Compares the urgent state of the window. Can be "latest" or "oldest".
+       Matches the latest or oldest urgent window, respectively.
+       (The following aliases are also available: newest, last, recent, first)
+con_mark::
+       Compares the mark set for this container, see <<vim_like_marks>>.
+con_id::
+       Compares the i3-internal container ID, which you can get via the IPC
+       interface. Handy for scripting.
+
+The criteria +class+, +instance+, +role+, +title+ and +mark+ are actually
+regular expressions (PCRE). See +pcresyntax(3)+ or +perldoc perlre+ for
+information on how to use them.
+
+[[exec]]
+
+=== Executing applications (exec)
+
+What good is a window manager if you can’t actually start any applications?
+The exec command starts an application by passing the command you specify to a
+shell. This implies that you can use globbing (wildcards) and programs will be
+searched in your $PATH.
+
+*Syntax*:
+------------------------------
+exec [--no-startup-id] command
+------------------------------
+
+*Example*:
+------------------------------
+# Start the GIMP
+bindsym mod+g exec gimp
+
+# Start the terminal emulator urxvt which is not yet startup-notification-aware
+bindsym mod+Return exec --no-startup-id urxvt
+------------------------------
+
+The +--no-startup-id+ parameter disables startup-notification support for this
+particular exec command. With startup-notification, i3 can make sure that a
+window appears on the workspace on which you used the exec command. Also, it
+will change the X11 cursor to +watch+ (a clock) while the application is
+launching. So, if an application is not startup-notification aware (most GTK
+and Qt using applications seem to be, though), you will end up with a watch
+cursor for 60 seconds.
+
 === Splitting containers
 
 The split command makes the current window a split container. Split containers
@@ -709,7 +1213,8 @@ bindsym mod+t floating toggle
 
 === Focusing/Moving containers
 
-To change the focus, use the focus command: +focus left+, +focus right+, +focus down+ and +focus up+.
+To change the focus, use the focus command: +focus left+, +focus right+, +focus
+down+ and +focus up+.
 
 There are a few special parameters you can use for the focus command:
 
@@ -724,12 +1229,27 @@ tiling::
        Sets focus to the last focused tiling container.
 mode_toggle::
        Toggles between floating/tiling containers.
+output::
+       Followed by a direction or an output name, this will focus the
+       corresponding output.
 
 For moving, use +move left+, +move right+, +move down+ and +move up+.
 
+*Syntax*:
+-----------------------------------
+focus <left|right|down|up>
+focus <parent|child|floating|tiling|mode_toggle>
+focus output <<left|right|down|up>|output>
+move <left|right|down|up> [<px> px]
+move [absolute] position [[<px> px] [<px> px]|center]
+-----------------------------------
+
+Note that the amount of pixels you can specify for the +move+ command is only
+relevant for floating containers. The default amount is 10 pixels.
+
 *Examples*:
 ----------------------
-# Focus clients on the left, bottom, top, right:
+# Focus container on the left, bottom, top, right:
 bindsym mod+j focus left
 bindsym mod+k focus down
 bindsym mod+l focus up
@@ -741,23 +1261,54 @@ bindsym mod+u focus parent
 # Focus last floating/tiling container
 bindsym mod+g focus mode_toggle
 
-# Move client to the left, bottom, top, right:
+# Focus the output right to the current one
+bindsym mod+x focus output right
+
+# Focus the big output
+bindsym mod+x focus output HDMI-2
+
+# Move container to the left, bottom, top, right:
 bindsym mod+j move left
 bindsym mod+k move down
 bindsym mod+l move up
 bindsym mod+semicolon move right
+
+# Move container, but make floating containers
+# move more than the default
+bindsym mod+j move left 20 px
+
+# Move floating container to the center
+# of all outputs
+bindsym mod+c move absolute position center
 ----------------------
 
-=== Changing workspaces/moving containers to workspaces
+=== Changing (named) workspaces/moving to workspaces
 
 To change to a specific workspace, use the +workspace+ command, followed by the
 number or name of the workspace. To move containers to specific workspaces, use
-+move workspace+.
++move container to workspace+.
 
 You can also switch to the next and previous workspace with the commands
 +workspace next+ and +workspace prev+, which is handy, for example, if you have
 workspace 1, 3, 4 and 9 and you want to cycle through them with a single key
-combination.
+combination. To restrict those to the current output, use +workspace
+next_on_output+ and +workspace prev_on_output+. Similarly, you can use +move
+container to workspace next+ and +move container to workspace prev+ to move a
+container to the next/previous workspace.
+
+[[back_and_forth]]
+To switch back to the previously focused workspace, use +workspace
+back_and_forth+.
+
+To move a container to another xrandr output such as +LVDS1+ or +VGA1+, you can
+use the +move container to output+ command followed by the name of the target
+output. You may also use +left+, +right+, +up+, +down+ instead of the xrandr
+output name to move to the next output in the specified direction.
+
+To move a whole workspace to another xrandr output such as +LVDS1+ or +VGA1+,
+you can use the +move workspace to output+ command followed by the name of the
+target output. You may also use +left+, +right+, +up+, +down+ instead of the
+xrandr output name to move to the next output in the specified direction.
 
 *Examples*:
 -------------------------
@@ -765,40 +1316,109 @@ bindsym mod+1 workspace 1
 bindsym mod+2 workspace 2
 ...
 
-bindsym mod+Shift+1 move workspace 1
-bindsym mod+Shift+2 move workspace 2
+bindsym mod+Shift+1 move container to workspace 1
+bindsym mod+Shift+2 move container to workspace 2
+...
+
+# switch between the current and the previously focused one
+bindsym mod+b workspace back_and_forth
+
+# move the whole workspace to the next output
+bindsym mod+x move workspace to output right
+-------------------------
+
+==== Named workspaces
+
+Workspaces are identified by their name. So, instead of using numbers in the
+workspace command, you can use an arbitrary name:
+
+*Example*:
+-------------------------
+bindsym mod+1 workspace mail
+...
+-------------------------
+
+If you want the workspace to have a number *and* a name, just prefix the
+number, like this:
+
+*Example*:
+-------------------------
+bindsym mod+1 workspace 1: mail
+bindsym mod+2 workspace 2: www
 ...
 -------------------------
 
+Note that the workspace will really be named "1: mail". i3 treats workspace
+names beginning with a number in a slightly special way. Normally, named
+workspaces are ordered the way they appeared. When they start with a number, i3
+will order them numerically. Also, you will be able to use +workspace number 1+
+to switch to the workspace which begins with number 1, regardless of which name
+it has. This is useful in case you are changing the workspace’s name
+dynamically.
+
+=== Renaming workspaces
+
+You can rename workspaces. This might be useful to start with the default
+numbered workspaces, do your work, and rename the workspaces afterwards to
+reflect what’s actually on them.
+
+*Syntax*:
+----------------------------------------------------
+rename workspace <old_name> to <new_name>
+----------------------------------------------------
+
+*Examples*:
+------------------------------------------------
+i3-msg 'rename workspace 5 to 6'
+i3-msg 'rename workspace 1 to "1: www"'
+i3-msg 'rename workspace "1: www" to "10: www"'
+------------------------------------------------
+
 [[resizingconfig]]
 
 === Resizing containers/windows
 
 If you want to resize containers/windows using your keyboard, you can use the
-+resize+ command, I recommend using it inside a so called +mode+:
++resize+ command:
+
+*Syntax*:
+---------------------------------------------------------
+resize <grow|shrink> <direction> [<px> px] [or <ppt> ppt]
+---------------------------------------------------------
+
+Direction can either be one of +up+, +down+, +left+ or +right+. Or you can be
+less specific and use +width+ or +height+, in which case i3 will take/give
+space from all the other containers. The optional pixel argument specifies by
+how many pixels a *floating container* should be grown or shrunk (the default
+is 10 pixels). The ppt argument means percentage points and specifies by how
+many percentage points a *tiling container* should be grown or shrunk (the
+default is 10 percentage points).
+
+I recommend using the resize command inside a so called +mode+:
 
 .Example: Configuration file, defining a mode for resizing
 ----------------------------------------------------------------------
 mode "resize" {
         # These bindings trigger as soon as you enter the resize mode
 
-        # They resize the border in the direction you pressed, e.g.
-        # when pressing left, the window is resized so that it has
-        # more space on its left
-
-        bindsym j resize shrink left
-        bindsym Shift+j resize grow left
-
-        bindsym k resize grow bottom
-        bindsym Shift+k resize shrink bottom
-
-        bindsym l resize shrink top
-        bindsym Shift+l resize grow top
-
-        bindsym semicolon resize grow right
-        bindsym Shift+semicolon resize shrink right
-
-        bindcode 36 mode default
+        # Pressing left will shrink the window’s width.
+        # Pressing right will grow the window’s width.
+        # Pressing up will shrink the window’s height.
+        # Pressing down will grow the window’s height.
+        bindsym j           resize shrink width 10 px or 10 ppt
+        bindsym k           resize grow height 10 px or 10 ppt
+        bindsym l           resize shrink height 10 px or 10 ppt
+        bindsym semicolon   resize grow width 10 px or 10 ppt
+
+        # same bindings, but for the arrow keys
+        bindsym Left        resize shrink width 10 px or 10 ppt
+        bindsym Down        resize grow height 10 px or 10 ppt
+        bindsym Up          resize shrink height 10 px or 10 ppt
+        bindsym Right       resize grow width 10 px or 10 ppt
+
+        # back to normal: Enter or Escape
+        bindsym Return mode "default"
+        bindsym Escape mode "default"
 }
 
 # Enter resize mode
@@ -931,6 +1551,40 @@ bindsym mod+Shift+w reload
 bindsym mod+Shift+e exit
 ----------------------------
 
+=== Scratchpad
+
+There are two commands to use any existing window as scratchpad window. +move
+scratchpad+ will move a window to the scratchpad workspace. This will make it
+invisible until you show it again. There is no way to open that workspace.
+Instead, when using +scratchpad show+, the window will be shown again, as a
+floating window, centered on your current workspace (using +scratchpad show+ on
+a visible scratchpad window will make it hidden again, so you can have a
+keybinding to toggle).
+
+As the name indicates, this is useful for having a window with your favorite
+editor always at hand. However, you can also use this for other permanently
+running applications which you don’t want to see all the time: Your music
+player, alsamixer, maybe even your mail client…?
+
+*Syntax*:
+---------------
+move scratchpad
+
+scratchpad show
+---------------
+
+*Examples*:
+------------------------------------------------
+# Make the currently focused window a scratchpad
+bindsym mod+Shift+minus move scratchpad
+
+# Show the first scratchpad window
+bindsym mod+minus scratchpad show
+
+# Show the sup-mail scratchpad window, if any.
+bindsym mod4+s [title="^Sup ::"] scratchpad show
+------------------------------------------------
+
 [[multi_monitor]]
 
 == Multiple monitors
@@ -1052,14 +1706,13 @@ If you don’t already have your favorite way of generating such a status line
 this task. It was written in C with the goal of using as few syscalls as
 possible to reduce the time your CPU is woken up from sleep states. Because
 i3status only spits out text, you need to combine it with some other tool, like
-i3bar. Use a pipe to connect them: +i3status | i3bar -d+.
+i3bar. See <<status_command>> for how to display i3status in i3bar.
 
 Regardless of which application you use to display the status line, you
 want to make sure that it registers as a dock window using EWMH hints. i3 will
 position the window either at the top or at the bottom of the screen, depending
-on which hint the application sets. With i3bar, you can use +-d+ or +-dbottom+
-for positioning it at the bottom and +-dtop+ to position it at the top of the
-screen.
+on which hint the application sets. With i3bar, you can configure its position,
+see <<i3bar_position>>.
 
 === Giving presentations (multi-monitor)