Proper customization at the keymap level is impossible due to _user() functions either being handled incorrectly or not returning a bool.
#8 246 ouverte le 25 févr. 2020
Métriques du dépôt
- Stars
- (20 368 stars)
- Métriques de merge PR
- (Merge moyen 20j 9h) (27 PRs mergées en 30 j)
Description
Incorrect handling of bool _user() functions
This is the advice given when writing a custom _kb() function, straight from the docs:
For process_record_kb() for example, that description would be roughly equal to this code structure:
bool process_record_kb(uint16_t keycode, keyrecord_t *record) {
if (!process_record_user(keycode, record)) {
return false;
}
// Do _kb stuff only if process_record_user() didn't already handle the key event.
}
Yet all implementations I could find of process_record_kb() look like this:
bool process_record_kb(uint16_t keycode, keyrecord_t *record) {
// Alway do _kb stuff, and potentially even skip process_record_user() with early return.
return process_record_user(keycode, record);
}
As a results you have to change code at the keyboard level if you want proper control at the keymap level.
No option of overwriting non-bool _kb() functions
The second part of this (which might even deserve its own issue), is that a lot of _user() and _kb() functions simply don't return a bool, which makes it impossible for the keyboard level to know if the user level already handled that functionality.
This includes things like void encoder_update_kb(), void matrix_init_kb(), void raw_hid_receive_kb(), void matrix_scan_kb() and a bunch more.