several improvements for mitosis:datagrok (#1960)

[qmk_firmware.git] / docs / custom_quantum_functions.md

diff --git a/docs/custom_quantum_functions.md b/docs/custom_quantum_functions.md
index 17615d991c732e2436b00dc08c90c7afc155b37b..10a718431c359e69c0916ecfc8b5861e7a8a8204 100644 (file)
--- a/docs/custom_quantum_functions.md
+++ b/docs/custom_quantum_functions.md
@@ -34,9 +34,9 @@ enum my_keycodes {
 };
 ```
 
-## Programming The Behavior Of A Keycode
+## Programming The Behavior Of Any Keycode
 
-When you want to override the behavior of an existing key, or define the behavior for a new key, you should use the `process_record_{kb,user}()` functions. These are called by QMK during key processing before the actual key event is handled. If these functions return `true` QMK will process the keycodes as usual. That can be handy for extending the functionality of a key rather than replacing it. If these functions return `false` QMK will skip the normal key handling, and it will be up you to send and key up or down events that are required.
+When you want to override the behavior of an existing key, or define the behavior for a new key, you should use the `process_record_kb()` and `process_record_user()` functions. These are called by QMK during key processing before the actual key event is handled. If these functions return `true` QMK will process the keycodes as usual. That can be handy for extending the functionality of a key rather than replacing it. If these functions return `false` QMK will skip the normal key handling, and it will be up you to send any key up or down events that are required.
 
 These function are called every time a key is pressed or released.
 
@@ -57,7 +57,7 @@ bool process_record_user(uint16_t keycode, keyrecord_t *record) {
     case KC_ENTER:
       // Play a tone when enter is pressed
       if (record->event.pressed) {
-        PLAY_NOTE_ARRAY(tone_enter);
+        PLAY_NOTE_ARRAY(tone_qwerty);
       }
       return true; // Let QMK send the enter press/release events
   }
@@ -86,7 +86,7 @@ keyrecord_t record {
 }
 ```
 
-## LED Control
+# LED Control
 
 This allows you to control the 5 LED's defined as part of the USB Keyboard spec. It will be called when the state of one of those 5 LEDs changes.
 
@@ -133,11 +133,11 @@ void led_set_kb(uint8_t usb_led) {
 * Keyboard/Revision: `void led_set_kb(uint8_t usb_led)` 
 * Keymap: `void led_set_user(uint8_t usb_led)`
 
-## Matrix Initialization Code
+# Matrix Initialization Code
 
 Before a keyboard can be used the hardware must be initialized. QMK handles initialization of the keyboard matrix itself, but if you have other hardware like LED's or i²c controllers you will need to set up that hardware before it can be used.
 
-#### Example `matrix_init_kb()` implementation
+### Example `matrix_init_kb()` implementation
 
 This example, at the keyboard level, sets up B1, B2, and B3 as LED pins.
 
@@ -158,7 +158,7 @@ void matrix_init_kb(void) {
 * Keyboard/Revision: `void matrix_init_kb(void)` 
 * Keymap: `void matrix_init_user(void)`
 
-## Matrix Scanning Code
+# Matrix Scanning Code
 
 Whenever possible you should customize your keyboard by using `process_record_*()` and hooking into events that way, to ensure that your code does not have a negative performance impact on your keyboard. However, in rare cases it is necessary to hook into the matrix scanning. Be extremely careful with the performance of code in these functions, as it will be called at least 10 times per second.