LockLayer/UnlockLayer cancels the effect of a OneShot modifier

[lobre]

Describe the bug

Here is what I read from the documentation for OneShots.

https://kaleidoscope.readthedocs.io/en/latest/plugins/Kaleidoscope-OneShot.html#oneshot

Furthermore, modifiers and other layer keys do not cancel the one-shot effect, either.

But it seems to me that for a OneShot modifier (let's say Left_Ctrl), using a LockLayer/UnlockLayer before the actual key on which the modifier should be applied cancels the effect of the OneShot (the key is output without its modifier applied).

To Reproduce

On my Linux machine, LeftGui+t opens a new terminal window. I was expecting the following steps to trigger this shortcut, but it does not seem to work as documented.

• I am on layer A on which is my t key.
• I lock layer B using a key that triggers LockLayer(B).
• I single tap the OneShot LeftGui key to enable it from this layer B.
• I go back to layer A using a key that triggers UnlockLayer(B).
• I tap t.

But it seems only t is typed, and not LeftGui+t.

Expected behavior

I was expecting LeftGui+t to happen so that my terminal shortcut is triggered. This should work even if the key on which I want the modifier applied is on a different layer than the OneShot modifier.

Environment (please complete the following information):

• OS: Ubuntu
• Version: 22.04
• Device Atreus

[gedankenexperimenter]

The status of this as a bug is debatable. The documentation ought to say "layer shift keys", not simply "layer keys". Other types of layer keys could also be included, and perhaps they should be, since those keys don't normally cause any HID reports to be sent to the host. It should be a simple change to this line.

[lobre]

Can I please ask what are the other types of "layer keys"? Does it mean that "layer lock" is another type of "layer key" different from "layer shift"?

[gedankenexperimenter]

There are several different types of Layer keys. "Layer shift" keys (e.g. ShiftToLayer(N)) behave like modifier keys. "Layer lock" keys (e.g. LockLayer(N)), bring the target layer to the top of the active layer stack, or if it's already there, deactivate it, behaving similarly to caps lock. There's also MoveToLayer(N), which deactivates all layers other than the target layer, and "ModLayer" keys, which combine a modifier key and a layer shift key.

The layer keys that don't trigger the release of a one-shot key are the "momentary" ones: layer shift and mod-layer keys. The documentation ought to reflect that. But it would also be quite reasonable to change the behavior of the OneShot plugin to also ignore layer lock and move keys when considering whether or not to trigger release of keys in the one-shot state.

[lobre]

Understood, thanks a lot for the precisions.

I would personally argue that LockLayer and MoveLayer should not deactivate the effect of one-shot keys. I don't see why there would be a difference with ShiftToLayer. It is just a different way of manipulating layers, so it does not seem logical to me that one-shot keys react differently for those.

If you agree, should I try to come up with a PR? I am a newcomer to the codebase, so any clues about what to be done would be appreciated. I understand this isMomentary function, but I am still not sure to understand the timeout and what I should do to have the same behaviour with LockLayer/MoveLayer.

[gedankenexperimenter]

I would personally argue that LockLayer and MoveLayer should not deactivate the effect of one-shot keys. I don't see why there would be a difference with ShiftToLayer. It is just a different way of manipulating layers, so it does not seem logical to me that one-shot keys react differently for those.

I think you've got a good case. I don't think we even considered the use of LockLayer() keys in the design of OneShot, especially because it's so natural to use one-shot layer keys in concert with one-shot modifiers.

Perhaps we should consider a broader redesign, rather than just exempting those non-momentary layer keys on the grounds that they don't cause HID reports to be sent to the host. Ideally, I think the fundamental question we'd want to ask when a non-OneShot, non-momentary key toggles on is "Was this key affected by the active one-shot key(s)?" In your example, for instance, it makes sense for a keyboard modifier in a one-shot state to not be affected by a layer lock key toggling on, but it does make sense for a layer shift key in a one-shot state to turn off in response to a layer lock key toggling on (or, even more convincingly, a MoveToLayer() key).

It is far from clear to me what the best option is.