Bug: numlock state gets changed despite overriding numlock key

[Wimads]

Just ran into a bug:

I have changed the function of the numlock key (its now an "n" key). While it does produce "n" as intended, it also still seems to change the numlock state, which is obviously not intended and affects the remapped keys in my numpad area.. This happens in both v1.4 and v1.3, on windows 11.

[jtroo]

This one is probably not fixable - I'm assuming you're using the standard executable as opposed to an interception variant?

There are instances where Windows will handle a keypress before kanata can do anything about it, and this may be one of those cases. E.g. see #192.

You could try the interception variant, but do note the warnings in the release page about issues with it. And the interception driver has incomplete support for keys as well (e.g. see #164 and #425). I should probably compile a document of known issues across the different variants of kanata at some point.

[Wimads]

Ok thanks, yeah I was affraid of that. Well, will need to work around it then. I guess I could tell kanata to also change the numlock state on pressing "n", to undo it.