qmk-keymap VS qmk_firmware

Yes, it is technically possible in QMK to record a history of the previous 2 keys (or more) to have a skipgram-reducing magic key. This is possible in QMK by saving the keycode for each event in a sliding buffer. See my example on triggering based on previously typed keys and the source for my Sentence Case for implementations of such a key history buffer. I see u/mEFErqlg shared an implementation as well in another comment thread.

I really appreciate all the work that's going into ZMK, and am by no means an expert on the limitations or architecture that they're working within, but personally feel that the recent macro-parameter implementation fails to elevate the Behavior[3] into a sufficiently powerful construct. I'm trying to imagine how it could offer greater composition and control over an invoked sequence of keycodes, key-positions, and behaviors, but if that ever comes to be, it will be on the shoulders of giants. Development has been very active, and the contributers have all done great work. Shoutout to zmk-nodefree-config[4] and thumbkey[5] for android, which has also been under rapid development from a wide group of contributers (special thx to WadeWT and sslater11, amoung many others).

[1]: https://github.com/getreuer/qmk-keymap/

Check out my keymap. My intention is to put a rather light load on the thumbs. Lately I've been doing this:

Uses getreuer's 400 entry autocorrect dictionary. https://github.com/getreuer/qmk-keymap/blob/main/features/autocorrection_dict_extra.txt

A cool thing with QMK is that you may insert arbitrary C code to handle key events. That's a lot of power, and I've been having fun with that. Check out my keymap. Some gems:

Please pull or re-download getreuer/qmk-keymap to get the latest.

I am a software engineer and use a 65% as my daily driver. 65% is enough for the most common keys including a number row on the a base layer, and I have special symbols and F-keys on a symbol layer (see my keymap). For me, the point of mechanical keyboards is ergonomics, and on that front I suggest a split, columnar keyboard with QMK or other programmable firmware. Here is a brief features tour of why I think these keyboards are so awesome.

I'm a software engineer and naturally spend a lot of my time at the computer writing code, plus quite a bit of non-code writing (emails, reviews, ...). Since RSI is something of an occupational hazard, mechanical keyboards are for me mainly about preventative ergonomics and comfort. Though, writing custom code within QMK keymap has interesting productive possibilities... I've been having fun with that.

You want fun experimental features?—check out my QMK repo =)

Combined with its separate hold behavior and some tap dancing on them in other layers, these keys does so much that I sometimes doubt it would all be possible with just two keys.

My layout has 34 keys and is optimized for software programming, with symbols spread across two layers, on the left side of the lower and on the right side of the raise layer, so you can reach all symbols with a single hand. It might worth checking if it fits your case, and you can always reposition the symbols according to your needs.

I use my BM40 as a daily driver for a few months now, also with a split layout.

I use a 34 keys layout in my planck, and put the symbols in the left side of the lower and right side of the raise layers, so that I can access them with a single hand, which for me feels more intuitive. < and > goes in the same positions as comma and dot, so I can also access them using shift, which I use mostly for indentation in VIM. {, (, [ and < are in the middle finger columns, above and below the home row, which makes them easier to access. The closing counterpart are not used so often, since the text editors type them automatically, so it is okay to improve for the position of the opening counterpart.

This is really nice. Thanks for sharing. I plan to do the same in the future with mine, but it still needs some cleaning and documentation.

I use keyboard-layout-editor.com to maintain my visual keymap and update the keymap.c manually, but formatting the code and comments to make it easier to read and edit. I've tried something like you are doing, but it did not worth it.

I'm a VIM user, but I rather use j as the left arrow instead of h, to avoid lateral movement, so I disabled hjkl in VIM and use my navigation layer instead, holding the left thumb. I use a lot of layers, but everything is easy to reach and remember. I also use a combo to activate the navigation layer using only the right hand. https://github.com/rafaelromao/qmk_firmware/tree/rafaelromao/keyboards/kprepublic/bm40hsrgb/keymaps/rafaelromao