ui.backend.windows: fix special treatment of the character keypresses

[alex-ilin]

Without this fix, Caps Lock state interferes with the shortcuts like
Ctrl-a by registering them as Ctrl-A, and it is also impossible to create
shortcuts with the Shift key to be triggered only by the physical pressing
of the Shift key, and not the Caps Lock state.

With this fix, all the key-down events for characters have the lower case
letter, and the Shift state reported in the mods field.

This patch solves the issue for the Windows platform, not any others, but the UI shortcut definitions are updated globally, so other platforms will probably lose the functions like A+S+k to clear the stack in the listener.

[mrjbq7]

Seems a lot less clear to do { S+ } "k" instead of "K"...

So what do you do with like "&"? ... is it now { S+ } "&"?

[timor]

Maybe I don't have the whole picture here, but I think there are two issues involved here, which are conceptually separate:

1. Whether or not caps lock should be treated as shift with regards to key bindings
2. How to define key bindings for shift+<key> combinations

As for 1., I think that the behavior should be platform-independent, but maybe made modal if some application UI logic requires that behavior. (For example, some computer game might want to use the caps lock key not as a modifier key, but actually handle key-up/key-down events?)

Regarding 2., I personally like the way it is currently defined (as described in the documentation).

[mrjbq7]

@erg any thoughts?

[nomennescio]

I agree with @timor, but want to add that typically handling keypresses is done at a lower level than getting typed in characters (think e.g. of multiple keypresses to compose unicode character input). Caps lock should not carry state into handling of keypresses, it should operate at the character input level (unless you want all applications to handle it themselves, which is ugly). That means that CAPSLOCK should become a key symbol that can be detected with key-up and key-down gestures. How to encode gestures in Factor should indeed stay independent of these choices. It might be enlightening to have a look at how Emacs solves it cross-platform.