summaryrefslogtreecommitdiff
path: root/specs/ch06.xml
diff options
context:
space:
mode:
authorMatt Dew <marcoz@osource.org>2011-03-15 23:30:15 -0600
committerMatt Dew <marcoz@osource.org>2011-03-21 23:01:15 -0600
commitb82c9b3f752c89d3328c0257d8a386024c9023ee (patch)
tree74abec1e9ef8ed01edc717599e8a6b3047b66290 /specs/ch06.xml
parentc336374f3bf34ce875b29001548470f8d824141e (diff)
Remove duplicate 'See see' text in docs - take 2
Diffstat (limited to 'specs/ch06.xml')
-rw-r--r--specs/ch06.xml16
1 files changed, 8 insertions, 8 deletions
diff --git a/specs/ch06.xml b/specs/ch06.xml
index 6476750..6351760 100644
--- a/specs/ch06.xml
+++ b/specs/ch06.xml
@@ -262,7 +262,7 @@ list of symbols associated with the key (i.e. it has one action per symbol
associated with the key). For key press events, the server looks up the action
to be applied from this list using the key symbol mapping associated with the
event key, just as a client looks up symbols as described in <link
-linkend="determining_the_keysym_associated_with_a_key_event">See Determining the KeySym Associated with a
+linkend="determining_the_keysym_associated_with_a_key_event">Determining the KeySym Associated with a
Key Event</link>; if the event key does not have any actions, the server uses
the <emphasis>
SA_NoAction</emphasis>
@@ -292,7 +292,7 @@ delay between the activation of one and the other.
<para>
Most actions which affect keyboard modifier state accept a modifier definition
-(see <link linkend="virtual_modifiers">See Virtual Modifiers</link>)
+(see <link linkend="virtual_modifiers">Virtual Modifiers</link>)
named <emphasis>
mods</emphasis>
and a boolean flag name <emphasis>
@@ -679,7 +679,7 @@ MouseKeysAccel</emphasis>
keyboard control is enabled, key press also initiates the mouse keys timer for
this key; every time this timer expires, the cursor moves again. The distance
the cursor moves in these subsequent events is determined by the mouse keys
-acceleration as described in <link linkend="the_mousekeysaccel_control">See The
+acceleration as described in <link linkend="the_mousekeysaccel_control">The
MouseKeysAccel Control</link>.
</para>
</listitem>
@@ -1627,7 +1627,7 @@ event that caused them.
Events sent to clients that have not issued an <emphasis>
XkbUseExtension</emphasis>
request contain a compatibility state in place of the actual XKB keyboard
-state. See <link linkend="effects_of_xkb_on_core_protocol_events">See Effects of XKB on Core
+state. See <link linkend="effects_of_xkb_on_core_protocol_events">Effects of XKB on Core
Protocol Events</link> for a description of this compatibility mapping.
</para>
@@ -1647,7 +1647,7 @@ the following changes:
<listitem>
<para>A passive grab triggers if the modifier state specified in the grab
matches the grab compatibility state (described in <link
-linkend="compatibility_components_of_keyboard_state">See Compatibility Components of Keyboard
+linkend="compatibility_components_of_keyboard_state">Compatibility Components of Keyboard
State</link>). Clients can choose to use the XKB grab state instead by setting
the <emphasis>
GrabsUseXKBState</emphasis>
@@ -1678,14 +1678,14 @@ LookupStateWhenGrabbed</emphasis>
<listitem>
<para>Otherwise, the state field of events that do not trigger a passive grab
report is derived from the XKB effective modifiers and group, as described in
-<link linkend="computing_a_state_field_from_an_xkb_state">See Computing A State Field from an
+<link linkend="computing_a_state_field_from_an_xkb_state">Computing A State Field from an
XKB State</link>.
</para>
</listitem>
<listitem>
<para>If a key release event is the result of an autorepeating key that is
being held down, and the client to which the event is reported has requested
-detectable autorepeat (see <link linkend="detectable_autorepeat">See
+detectable autorepeat (see <link linkend="detectable_autorepeat">
Detectable Autorepeat</link>), the event is not delivered to the client.
</para>
</listitem>
@@ -1720,7 +1720,7 @@ interact.
<listitem>
<para>The largest problems arise from the fact that an XKB state field
encodes an explicit keyboard group in bits 13-14 (as described in <link
-linkend="computing_a_state_field_from_an_xkb_state">See Computing A State Field from an XKB
+linkend="computing_a_state_field_from_an_xkb_state">Computing A State Field from an XKB
State</link>), while pre-XKB clients use one of the eight keyboard modifiers
to select an alternate keyboard group. To make existing clients behave
reasonably, XKB normally uses the compatibility grab state instead of the XKB