Added the proper provision for numeric keypad entry.

1 files changed, 2 insertions, 1 deletions

diff --git a/areaplan.md b/areaplan.md
index 44ea8d6..c5000b6 100644
--- a/areaplan.md
+++ b/areaplan.md
@@ -1137,5 +1137,6 @@ There are a few loose ends:
 * Can the OS X key codes be used to differentiate between numpad keys and non-numpad keys regardless of num lock state? If so, we can safely differentiate between the two, and can get rid of that arbitrary restriction.
 	* TODO
 * Can we also use scancodes for the numeric keypad, **including** the numeric keypad / key? GDK keysyms have Num Lock interpreted; we don't want that. This is just adding the scancodes for the numeric keypad to our test above...
-	 * TODO
+	* We only need to worry about the number keys and ., it seems; everything else is unaffected by Num Lock (and uses extended scancodes, so.)
+	* Okay, the numeric keys and . use the same scancodes and evdev key code values, so we can handle them with scancodes too.
 * The GLFW source does not use the scancode 0x2B for \, claiming that it only exists on US keyboards (instead it uses one of the OEM virtual key codes on Windows). This goes against the Scan Codes Demystified page, which says that on international keyboards, that would be another key (with region-specific label) underneath and to the right of what would be the [ and ] keys on a US keyboard. This appears to be true in some cases; in others, the extra key is to the left of Backspace instead. Either way, this is close enough to the \ key's position on a US keyboard that we can just go ahead and use 0x2B anyway.