doc/quick-guide: small improvements

Signed-off-by: Ran Benita <ran234@gmail.com>

1 files changed, 11 insertions, 13 deletions

diff --git a/doc/quick-guide.md b/doc/quick-guide.md
index 3cf5b3b..972d09c 100644
--- a/doc/quick-guide.md
+++ b/doc/quick-guide.md
@@ -27,8 +27,7 @@ xkbcommon/ for more details.
 
 ## Code
 
-Before we can do anything interesting, we need a library context. So
-let's create one:
+Before we can do anything interesting, we need a library context:
 
 ~~~{.c}
     #include <xkbcommon/xkbcommon.h>
@@ -39,10 +38,10 @@ let's create one:
     if (!ctx) <error>
 ~~~
 
-The xkb_context contains the keymap include paths, the log level and
+The `xkb_context` contains the keymap include paths, the log level and
 functions, and other general customizable administrativia.
 
-Next we need to create a keymap, xkb_keymap. This is an immutable object
+Next we need to create a keymap, `xkb_keymap`. This is an immutable object
 which contains all of the information about the keys, layouts, etc. There
 are different ways to do this.
 
@@ -50,8 +49,8 @@ If we are an evdev client, we have nothing to go by, so we need to ask
 the user for his/her keymap preferences (for example, an Icelandic
 keyboard with a Dvorak layout). The configuration format is commonly
 called RMLVO (Rules+Model+Layout+Variant+Options), the same format used
-by the X server. With it, we can fill a struct called xkb_rule_names;
-passing NULL chooses the system's default.
+by the X server. With it, we can fill a struct called `xkb_rule_names`;
+passing `NULL` chooses the system's default.
 
 ~~~{.c}
     struct xkb_keymap *keymap;
@@ -101,7 +100,7 @@ we will use the core keyboard device:
 ~~~
 
 Now that we have the keymap, we are ready to handle the keyboard devices.
-For each device, we create an xkb_state, which remembers things like which
+For each device, we create an `xkb_state`, which remembers things like which
 keyboard modifiers and LEDs are active:
 
 ~~~{.c}
@@ -118,7 +117,7 @@ For X11/XCB clients, this is better:
     if (!state) <error>
 ~~~
 
-When we have an xkb_state for a device, we can start handling key events
+When we have an `xkb_state` for a device, we can start handling key events
 from it.  Given a keycode for a key, we can get its keysym:
 
 ~~~{.c}
@@ -165,7 +164,7 @@ We can also get a UTF-8 string representation for this key:
     xkb_state_key_get_utf8(state, keycode, buffer, size);
 ~~~
 
-Of course, we also need to keep the xkb_state up-to-date with the
+Of course, we also need to keep the `xkb_state` up-to-date with the
 keyboard device, if we want to get the correct keysyms in the future.
 
 If we are an evdev client, we must let the library know whether a key
@@ -183,7 +182,7 @@ is pressed or released at any given time:
 The `changed` return value tells us exactly which parts of the state
 have changed.
 
-If is is a key-repeat event, we can ask the keymap what to do with it:
+If it is a key-repeat event, we can ask the keymap what to do with it:
 
 ~~~{.c}
     if (<key repeat> && !xkb_keymap_key_repeats(keymap, keycode))
@@ -205,7 +204,7 @@ information usually comes in a form of some "state changed" event):
                                     event->locked_layout);
 ~~~
 
-Now that we have an always-up-to-date xkb_state, we can examine it.
+Now that we have an always-up-to-date `xkb_state`, we can examine it.
 For example, we can check whether the Control modifier is active, or
 whether the Num Lock LED is active:
 
@@ -218,8 +217,7 @@ whether the Num Lock LED is active:
         <The Num Lock LED is active>
 ~~~
 
-And that's it! When we're finished, we should free the objects we've
-created:
+And that's it! Eventually, we should free the objects we've created:
 
 ~~~{.c}
     xkb_state_unref(state);