Sometimes one may need to use explicit actions in the xkb_symbols section, but not for all levels. Levels without action must still be fill in with NoAction(). However, specifying any other action makes the whole group have explicit actions, resulting in interprets not triggering with levels with NoAction(), which is probably not intended.
Example:
xkb_keymap {
xkb_keycodes {
<AD01> = 24;
<LFSH> = 50;
<RTSH> = 62;
};
xkb_types {
type "TWO_LEVEL" {
modifiers = Shift;
map[Shift] = 2;
};
};
xkb_compat {
interpret Shift {
action=SetMods(mods=Shift);
};
};
xkb_symbols {
key <LFSH> { [Shift_L] };
key <RTSH> { [Shift_R, any], [NoAction(), LockGroup(group=2)] };
key <AD01> { [q, Q], [a, A] };
};
};
<RTSH> will not activate the Shift modifier!
This is unfortunate, although it matches the xkbcomp behavior.
Since we now have VoidAction(), it would be better to trigger interprets iif there is no explicit action or on any explicit NoAction().
I think the impact would be minimal, but in doubt this can be limited to the keymap V2 format.
Sometimes one may need to use explicit actions in the
xkb_symbolssection, but not for all levels. Levels without action must still be fill in withNoAction(). However, specifying any other action makes the whole group have explicit actions, resulting in interprets not triggering with levels withNoAction(), which is probably not intended.Example:
<RTSH>will not activate theShiftmodifier!This is unfortunate, although it matches the
xkbcompbehavior.Since we now have
VoidAction(), it would be better to trigger interprets iif there is no explicit action or on any explicitNoAction().I think the impact would be minimal, but in doubt this can be limited to the keymap V2 format.