Subset comparison was introduced with the rather large commit
bf3cd41b5d, but I now think we should use
equality.
In other words, the following key binding:
bindsym Mod4+x nop Mod4+x
previously would have been triggered when pressing Mod3+Mod4+x.
Strictly speaking, this is a change of behavior, but it breaks none of our
tests, and using equality instead of subset comparison enables more use-cases.
fixes#2002
Before this commit, i3 only compared the user-specified modifiers and
incorrectly ignored the resolved modifiers (such as the numlock
fallback).
While at it, also fix the testcase which treated numlock as a momentary
modifier, whereas it really is a latched modifier.
fixes#2418
Previously, we always discarded the NumLock bit when looking up key
bindings for key press events, and we always grabbed every keycode with
and without the NumLock modifier.
With this commit, the NumLock bit is no longer discarded: since the
previous commit 3bd5e6e5c8 we can
correctly look up key bindings with/without the NumLock bit, as both
variants are stored in |keycodes_head|.
Further, before adding the NumLock fallback (resulting in grabbing the
keycode with the NumLock modifier), we now check whether the key has the
same meaning when NumLock is enabled. This correctly distinguishes the
KP_End vs. KP_1 case, i.e. one can now use the following key bindings:
# No longer accidentally triggered when pressing KP_1.
bindsym KP_End nop KP_End
# Properly distinguished now:
bindsym KP_End nop KP_End
bindsym Mod2+KP_1 nop KP_1
fixes#2346
Michael Stapelberg