Add user-overridable callback for cancelling UCIS input (#5564)

[qmk_firmware.git] / docs / how_keyboards_work.md

diff --git a/docs/how_keyboards_work.md b/docs/how_keyboards_work.md
index cc54e566a1f1c24c8afd01833d99a88b6c0dc98c..5697a21872c052552c261e82f42821e3741b2dd2 100644 (file)
--- a/docs/how_keyboards_work.md
+++ b/docs/how_keyboards_work.md
@@ -12,7 +12,7 @@ place:
 ``` text
 +------+         +-----+       +----------+      +----------+     +----+
 | User |-------->| Key |------>| Firmware |----->| USB wire |---->| OS |
-+------+         +-----+       +----------+      +----------+     |----+
++------+         +-----+       +----------+      +----------+     +----+
 ```
 
 This scheme is a very simple view of what's going on, and more details follow
@@ -63,10 +63,10 @@ You may wonder why a keyboard layout containing all of Unicode is not devised th
 
 ## How to (Maybe) Enter Unicode Characters
 
-You can have the firmware send *sequences of keys* to use the [software Unicode Input Method](https://en.wikipedia.org/wiki/Unicode_input#Hexadecimal_code_input) of the target operating system, thus effectively entering characters independently of the layout defined in the OS.
+You can have the firmware send *sequences of keys* to use the [software Unicode Input Method](https://en.wikipedia.org/wiki/Unicode_input#Hexadecimal_input) of the target operating system, thus effectively entering characters independently of the layout defined in the OS.
 
 Yet, it does come with multiple disadvantages:
 
- - Tied to a specific OS a a time (need recompilation when changing OS);
+ - Tied to a specific OS at a time (need recompilation when changing OS);
  - Within a given OS, does not work in all software;
  - Limited to a subset of Unicode on some systems.