Open amacleod opened 1 month ago
To be clear, I consider this an extremely minor nice-to-have. At some point I might take a crack at a PR for it, but only after learning more about ZMK internals 😄
If it's possible to calculate the number of combos using each key at compile time in order to check if it exceeds the max, then it should also be possible to just calculate what the max should be and eliminate the need for the setting entirely.
(That said, the typical method of getting the max of a list of numbers with C macros increases exponentially in complexity with the size of the list, so we would need to be sure such a solution is feasible on large keyboards.)
Could one overload west build
with a custom west command that's a shallow Python wrapper around the original one?
One could run the config through the preprocessor first and then use python to parse and automate various settings.
One might also do the same to improve error messages. E.g., showing the code corresponding to problematic columns after all macros have been expanded.
I took a stab at this, and have a POC branch for adding static asserts to introduce compilation errors for excessive combos, here: https://github.com/angweekiat/zmk-strip-kit46/pull/1
I also tried to see if it's possible to calculate CONFIG_ZMK_COMBO_MAX_KEYS_PER_COMBO
at compile time, and while I was able to get the list of combo key positions, I wasn't able to find a nice and scalable way to find the max value of the list at compile time :/
As a quality of life feature, it would be nice to have a way to automatically detect excess combos and issue a compile time warning. Or possibly even use that detection to implicitly increase the combo-per-key limit within reason.
Currently, if I overload a key with more combos than
CONFIG_ZMK_COMBO_MAX_COMBOS_PER_KEY
allows, it seems I silently lose the use of one or more of those combos. Rather than discovering this when I try to use that combo, I would prefer to have an error or warning when I (or the GH Action) go to build the firmware.