I saw this have been raised before, but since I'm experiencing a similar problem on the current version here is a new issue.
Using a plank when I hold ctrl and then hold the raise layer to access a symbol if I release first the ctrl key and then the raise layer the modifier gets stuck.
I notice this using emacs, for a brief moment I thought I was using vim on visual mode 😜
I'm seeing a similar issue.
reproduction steps:
Create a keyboard with 2 layers. The bottom layer should have a MO(1) key and the top layer should have a modifier key
Press the MO key
Press the modifier key on the top layer
Release the MO key
Release the modifier key
You will now be stuck with that modifier key active until you press MO->press modifier->release modifier->release MO
It seems like the modifier key triggers the modifier state on keydown and removes it on keyup, but when you press then change layers then release you are now keyup-ing the key on the bottom layer, which won't turn the modifier off
One possible fix would be to trigger keyup on all keys when leaving a MOmentary layer, but that could have some weird side effects.
Ideally if you pressed a key on a particular layer it would remain that key until you released it regardless of layer changes, but that could be difficult to implement
I found a solution to my problem in #182. There is already a framework in place to make modifiers 'weak' so that they will be cleared on a layer change. This is a better version of my first suggestion above.
Even better, 182 got merged. From the readme:
Prevent stuck modifiers
Consider the following scenario:
Layer 0 has a key defined as Shift.
The same key is defined on layer 1 as the letter A.
User presses Shift.
User switches to layer 1 for whatever reason.
User releases Shift, or rather the letter A.
User switches back to layer 0.
Shift was actually never released and is still considered pressed.
If such situation bothers you add this to your config.h:
This option uses 5 bytes of memory per every 8 keys on the keyboard rounded up (5 bits per key). For example on Planck (48 keys) it uses (48/8)*5 = 30 bytes.
Thank you @lordchair this completely solves my problem. Added that to my keymap config and it works as expected.
Most helpful comment
Even better, 182 got merged. From the readme:
Prevent stuck modifiers
Consider the following scenario:
Layer 0 has a key defined as Shift.
The same key is defined on layer 1 as the letter A.
User presses Shift.
User switches to layer 1 for whatever reason.
User releases Shift, or rather the letter A.
User switches back to layer 0.
Shift was actually never released and is still considered pressed.
If such situation bothers you add this to your config.h:
define PREVENT_STUCK_MODIFIERS
This option uses 5 bytes of memory per every 8 keys on the keyboard rounded up (5 bits per key). For example on Planck (48 keys) it uses (48/8)*5 = 30 bytes.