Actions: Break latch on modifier/group changes

[fooishbar]

Right now, only a few actions result in breaking a key latch. Add modifier/group actions to this, as presumably the effect of the latch should not last beyond already shifting the modifier/group state.

This was discovered with a real-world use in an input device for the physically impaired, where shift latches, but pressing shift twice goes to caps lock (note shift vs. caps lock, so not pure latch-to-lock). This is possible to implement with current keymap files, but locking caps lock would not break the shift latch. Hence, the following key sequence:

[Shift] [a -> A] [Shift] [Shift -> Lock] [b -> b] [c -> C]

would occur, as the modifier state when pressing b was lock locked and shift latched. With this patch, the sequence is correct:

[Shift] [a -> A] [Shift] [Shift -> Lock] [b -> B] [c -> C]

[bluetech]

I am very unfamiliar with latching but I have a question.

Let's say I configured LSHIFT and LCTRL to produce latching Shift and Control modifiers (e.g. like StickyKeys but configured directly in the keymap). If I want to type Shift+Control+Z, the key sequence I would expect to type is (correct me if I'm wrong)

LSHIFT      down
LSHIFT      up
LCTRL       down
LCTRL       up
Z           down
Z           up

If I understand the patch correctly, it will break that, since the LCTRL down would release the LSHIFT latch?

[fooishbar]

Ugh, yes, I'd not really thought of that. Frustrating.

I think the only other option I can see is to expand the syntax to allow Set/Latch/LockMods() actions to be able to clear other mods at the same time.

[bluetech]

I am trying to understand the problem.

Can you provide the keymap configuration that causes the sequence you specified to occur? I think maybe you mean something like the following?

LSHIFT level 1 (=> no mods active):  LatchMods(Shift)
LSHIFT level 2 (=> Shift is active): LockMods(Lock)

But then the first part of the key sequence is already confusing to me. If shift latches, why is it [Shift] [a -> a] and not [Shift] [a -> A]?

About the second part of the sequence, is the problem that because both Shift and Lock are active, you get [b -> b] (they "cancel" each other), and you want to only have Lock active at this point, to get [b -> B]?

[fooishbar]

Yes, sorry. I was thinking when I was walking home that I should've included a testcase, but thought I could get away with it until tomorrow at least. ;) Anyway, I've updated the commit to include one now.

You're right with everything: in what I'm after (shift once to LatchMods(Shift), shift twice in a row to LockMods(Lock)), that I got the commit message wrong (obviously Shift+a should produce A rather than a), and the problem being that the latching of shift persists and cancels caps. Cancelling is actually desired here, so whilst moving to nocancel would avoid the carry-over issue, it's not the desired behaviour.

[fooishbar]

@bluetech Any thoughts? AFAICS, it's either this, or make new syntax:

action= LockMods(modifier=Lock,clearMods=Shift) # almost exists already
action= LockMods(modifier=Lock,clearLatches) # completely new, similar to clearLocks