PR requested changes

docs/keys.md

@@ -23,27 +23,27 @@ The next few steps are the interesting part, but to understand them, we need to
 understand a bit about what a `Key` object is (found in `kmk/keys.py`). `Key`
 objects have a few core pieces of information:
 
-* Their `code`, which can be any integer. Integers below
+- Their `code`, which can be any integer. Integers below
   `FIRST_KMK_INTERNAL_KEY` are sent through to the HID stack (and thus the
   computer, which will translate that integer to something meaningful - for
   example, `code=4` becomes `a` on a US QWERTY/Dvorak keyboard).
 
-* Their attached modifiers (to implement things like shifted keys or `KC.HYPR`,
+- Their attached modifiers (to implement things like shifted keys or `KC.HYPR`,
   which are single key presses sending along more than one key in a single HID
   report. This is a distinct concept from Sequences, which are a KMK feature
   documented in `sequences.md`). For almost all purposes outside of KMK core,
   this field should be ignored - it can be safely populated through far more
   sane means than futzing with it by hand.
 
-* Some data on whether the key should actually be pressed or released - this is
+- Some data on whether the key should actually be pressed or released - this is
   mostly an implementation detail of how Sequences work, where, for example,
   `KC.RALT` may need to be held down for the entirety of a sequence, rather than
-  being released immediately before moving to the next character.  Usually end
+  being released immediately before moving to the next character. Usually end
   users shouldn't need to mess with this, but the fields are called `no_press`
   and `no_release` and are referenced in a few places in the codebase if you
   need examples.
 
-* Handlers for "press" (sometimes known as "keydown") and "release" (sometimes
+- Handlers for "press" (sometimes known as "keydown") and "release" (sometimes
   known as "keyup") events. KMK provides handlers for standard keyboard
   functions and some special override keys (like `KC.GESC`, which is an enhanced
   form of existing ANSI keys) in `kmk/handlers/stock.py`, for layer switching in
@@ -51,10 +51,10 @@ objects have a few core pieces of information:
   `sequences.md` again) in `kmk/handlers/sequences.py`. We'll discuss these more
   shortly.
 
-* Optional callbacks to be run before and/or after the above handlers. More on
+- Optional callbacks to be run before and/or after the above handlers. More on
   that soon.
 
-* A generic `meta` field, which is most commonly used for "argumented" keys -
+- A generic `meta` field, which is most commonly used for "argumented" keys -
   objects in the `KC` object which are actually functions that return `Key`
   instances, which often need to access the arguments passed into the "outer"
   function. Many of these examples are related to layer switching - for example,
@@ -121,6 +121,7 @@ whatever the stock handler is, you're covered. This also means you can add
 completely new functionality to KMK by writing your own handler.
 
 Here's an example of an after_press_handler to change the RGB lights with a layer change:
+
 ```python
 LOWER = KC.DF(LYR_LOWER) #Set layer to LOWER
 
@@ -130,10 +131,11 @@ def low_lights(key, keyboard, *args):
 
 LOWER.after_press_handler(low_lights) #call the key with the after_press_handler
 ```
+
 Here's an example of a lifecycle hook to print a giant Shrek ASCII art. It
 doesn't care about any of the arguments passed into it, because it has no
 intentions of modifying the internal state. It is purely a [side
-effect](https://en.wikipedia.org/wiki/Side_effect_(computer_science)) run every
+effect](<https://en.wikipedia.org/wiki/Side_effect_(computer_science)>) run every
 time Left Alt is pressed:
 
 ```python
@@ -168,16 +170,18 @@ SHREKLESS_ALT = KC.LALT.clone()
 ```
 
 You can also refer to a key by index:
-* KC['A']
-* KC['NO']
-* KC['LALT']
 
-or the get function which has an optional argument of `default`. `default` is
-be returned if the key is not found (`None` unless otherwise specified):
-* KC.get('A')
-* KC.get('NO', None)
-* KC.get('NOT DEFINED', KC.RALT)
+- `KC['A']`
+- `KC['NO']`
+- `KC['LALT']`
 
-Keys names are case-sensitive.  KC['NO'] being different from KC['no']. It is recommended
-that names are capitalised typically. The exception to this is alphabetical; KC['A'] and
-KC['a'] will both return the same, unshifted, key.
+Or the `KC.get` function which has an optional default argument, which will
+be returned if the key is not found (`default=None` unless otherwise specified):
+
+- `KC.get('A')`
+- `KC.get('NO', None)`
+- `KC.get('NOT DEFINED', KC.RALT)`
+
+Key names are case-sensitive. `KC['NO']` is different from `KC['no']`. It is recommended
+that names are normally UPPER_CASE. The exception to this are alpha keys; `KC['A']` and
+`KC['a']` will both return the same, unshifted, key.