QMK Link Time

So having got the new build process working as expected (some python ~/.local cache storage issue), link time optimization provides almost 4 kB for future features. Latest master build this is quite a lot of feature space when considering such a small microcontroller. A nice feature added to the more modern build options.

I should be able to put together a nice Crimbo update with such a gargantuan amount of code memory, and no need to duplicate features the computer should do easily. In some ways the difficulty is making something extra which might get used.

Docs for amperzand is a little experiment in server languages I’m thinking about. Anonymous inner class? Sounds like it might be cool. So there is still about 3 kB left after double striked letters (for drop capitals perhaps). So some 46 macros to define before I have to get a little more creative in what’s available.

And now added automatic South Korean sylibilic combintions.  

Ltd. Still and QMK.

Yes the QMK active branch and some news that my accounts are now filed. Zero in/zero out as a boring COVID an low contact availability year. So Ltd. status continues as far as I’m aware. I’ll keep you all informed.

So now the send_unicode_string() function is used for a macro system within the keymap latest coding. This is opposed to how the macro layer emits function key combinations, which is more in line for a tool on the computer handling it. I’ve also added repeated substring compression too. (“\\0” to “\\9”)

So more of a hard baked solution, but does allow more complex multi-character glyphs to be produced instead of just one Unicode code point. So with about 1100 bytes free about, that’s about thirty UTF-8 bytes per key action (over the 37 defined key action macros). Even “\\\\” is defined for emitting an initial backslash, just so backslash can be used as a prefix for more complex macro processing than just print until end of string.

Other macro features like tapping key codes for nested macros? Yes, if the keycode is added to the array so “\\A” will tap the first keycode.

QMK Keyboard Again

Latest 2021-11-22 commit goes for an 10 layer design with the language BQN built in and three further planes of Unicode glyphs. This leaves 2296 bytes of firmware left for further adaptions. Seems the lock key option consumes quite a bit and I don’t need it.

Altering the U’ ‘ defines such that a Unicode glyph is copied between the single quotes would add a Unicode character to the design.

The control iconographs for example:

[IAT] = U'⚠', [IA] = U'⟁', [IB] = U'🗚', [IC] = U'🗐',
[ID] = U'🔖', [IE] = U'🔎', [IF] = U'👍', [IG] = U'🔔',
[IH] = U'⌫', [II] = U'⭾', [IJ] = U'⏎', [IK] = U'⭿',
[IL] = U'📇', [IM] = U'✓', [IN] = U'🗋', [IO] = U'🗁',
[IP] = U'🐧', [IQ] = U'📤', [IR] = U'📥', [IS] = U'💾',
[IT] = U'🌱', [IU] = U'👎', [IV] = U'📋', [IW] = U'🔑',
[IX] = U'🗙', [IY] = U'🗜', [IZ] = U'⎌', [ILBR] = U'⎋',
[IBSL] = U'🌍', [IRBR] = U'☣', [ICAR] = U'⚗', [IUND] = U'☢',
 
Are picked to represent general principals of the control characters in a modern computer environment. Some of them may be difficult to understand at first but for example the last row could be considered ECO/BIO/CHEM/PHYS, on a atomic building.
 
Deciding on the extra control layer glyphs as they don’t have ASCII slots but are possible to type is a bit more complicated. I’ll give them a bit more thought. 
 
There’s an interesting VSCode crash 139 development (SEGMENTATION FAULT) just occurred which shouldn’t be happening but is a crash in the rendering process. Obviously some “bad code” in VSCode?
 
I’ve improved the shift mechanism for some of the extended layers, and filled in the ANSI control code layer to my satisfaction. I’ve finalized the Navigation and Macro layers to final satifaction and added a number lock on the Magenta shift of the Macro Yellow layer.