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.

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.