Merge branch '3.3-stable' into new-cursors-on-3.3-stable

docs/input.dox

@@ -24,7 +24,7 @@ All input callbacks receive a window handle.  By using the
 or objects from your callbacks.
 
 To get a better feel for how the various events callbacks behave, run the
-`events` test program.  It register every callback supported by GLFW and prints
+`events` test program.  It registers every callback supported by GLFW and prints
 out all arguments provided for every event, along with time and sequence
 information.
 
@@ -95,7 +95,7 @@ new size before everything returns back out of the @ref glfwSetWindowSize call.
 
 GLFW divides keyboard input into two categories; key events and character
 events.  Key events relate to actual physical keyboard keys, whereas character
-events relate to the Unicode code points generated by pressing some of them.
+events relate to the text that is generated by pressing some of them.
 
 Keys and characters do not map 1:1.  A single key press may produce several
 characters, and a single character may require several keys to produce.  This
@@ -123,23 +123,39 @@ void key_callback(GLFWwindow* window, int key, int scancode, int action, int mod
 }
 @endcode
 
-The action is one of `GLFW_PRESS`, `GLFW_REPEAT` or `GLFW_RELEASE`.  The key
-will be `GLFW_KEY_UNKNOWN` if GLFW lacks a key token for it, for example
-_E-mail_ and _Play_ keys.
+The action is one of `GLFW_PRESS`, `GLFW_REPEAT` or `GLFW_RELEASE`.  Events with
+`GLFW_PRESS` and `GLFW_RELEASE` actions are emitted for every key press.  Most
+keys will also emit events with `GLFW_REPEAT` actions while a key is held down.
+
+Note that many keyboards have a limit on how many keys being simultaneous held
+down that they can detect.  This limit is called
+[key rollover](https://en.wikipedia.org/wiki/Key_rollover).
+
+Key events with `GLFW_REPEAT` actions are intended for text input.  They are
+emitted at the rate set in the user's keyboard settings.  At most one key is
+repeated even if several keys are held down.  `GLFW_REPEAT` actions should not
+be relied on to know which keys are being held down or to drive animation.
+Instead you should either save the state of relevant keys based on `GLFW_PRESS`
+and `GLFW_RELEASE` actions, or call @ref glfwGetKey, which provides basic cached
+key state.
+
+The key will be one of the existing [key tokens](@ref keys), or
+`GLFW_KEY_UNKNOWN` if GLFW lacks a token for it, for example _E-mail_ and _Play_
+keys.
 
 The scancode is unique for every key, regardless of whether it has a key token.
 Scancodes are platform-specific but consistent over time, so keys will have
 different scancodes depending on the platform but they are safe to save to disk.
-You can query the scancode for any [named key](@ref keys) on the current
-platform with @ref glfwGetKeyScancode.
+You can query the scancode for any [key token](@ref keys) supported on the
+current platform with @ref glfwGetKeyScancode.
 
 @code
 const int scancode = glfwGetKeyScancode(GLFW_KEY_X);
 set_key_mapping(scancode, swap_weapons);
 @endcode
 
-The last reported state for every [named key](@ref keys) is also saved in
-per-window state arrays that can be polled with @ref glfwGetKey.
+The last reported state for every physical key with a [key token](@ref keys) is
+also saved in per-window state arrays that can be polled with @ref glfwGetKey.
 
 @code
 int state = glfwGetKey(window, GLFW_KEY_E);
@@ -152,7 +168,8 @@ if (state == GLFW_PRESS)
 The returned state is one of `GLFW_PRESS` or `GLFW_RELEASE`.
 
 This function only returns cached key event state.  It does not poll the
-system for the current physical state of the key.
+system for the current state of the physical key.  It also does not provide any
+key repeat information.
 
 @anchor GLFW_STICKY_KEYS
 Whenever you poll state, you risk missing the state change you are looking for.
@@ -183,15 +200,15 @@ Lock was on when the event occurred and the @ref GLFW_MOD_NUM_LOCK bit set if
 Num Lock was on.
 
 The `GLFW_KEY_LAST` constant holds the highest value of any
-[named key](@ref keys).
+[key token](@ref keys).
 
 
 @subsection input_char Text input
 
 GLFW supports text input in the form of a stream of
 [Unicode code points](https://en.wikipedia.org/wiki/Unicode), as produced by the
-operating system text input system.  Unlike key input, text input obeys keyboard
-layouts and modifier keys and supports composing characters using
+operating system text input system.  Unlike key input, text input is affected by
+keyboard layouts and modifier keys and supports composing characters using
 [dead keys](https://en.wikipedia.org/wiki/Dead_key).  Once received, you can
 encode the code points into UTF-8 or any other encoding you prefer.
 
@@ -370,7 +387,7 @@ sequential rows, starting from the top-left corner.
 @subsubsection cursor_standard Standard cursor creation
 
 A cursor with a [standard shape](@ref shapes) from the current system cursor
-theme can be can be created with @ref glfwCreateStandardCursor.
+theme can be created with @ref glfwCreateStandardCursor.
 
 @code
 GLFWcursor* url_cursor = glfwCreateStandardCursor(GLFW_POINTING_HAND_CURSOR);
@@ -478,8 +495,9 @@ void mouse_button_callback(GLFWwindow* window, int button, int action, int mods)
 
 The action is one of `GLFW_PRESS` or `GLFW_RELEASE`.
 
-Mouse button states for [named buttons](@ref buttons) are also saved in
-per-window state arrays that can be polled with @ref glfwGetMouseButton.
+The last reported state for every [supported mouse button](@ref buttons) is also
+saved in per-window state arrays that can be polled with @ref
+glfwGetMouseButton.
 
 @code
 int state = glfwGetMouseButton(window, GLFW_MOUSE_BUTTON_LEFT);
@@ -512,7 +530,7 @@ had been processed in the meantime, the state will reset to `GLFW_RELEASE`,
 otherwise it will remain `GLFW_PRESS`.
 
 The `GLFW_MOUSE_BUTTON_LAST` constant holds the highest value of any
-[named button](@ref buttons).
+[supported mouse button](@ref buttons).
 
 
 @subsection scrolling Scroll input