Re: Caps Lock affects Ctrl+keys

[Yuri Khan <yuri.v.khan@gmail.com>]

On Mon, Jan 20, 2014 at 6:57 PM, Yuri Khan <yuri.v.khan@gmail.com> wrote:

> I notice that, when I turn on Caps Lock, all Ctrl+letter combinations
> behave as if I pressed Ctrl+Shift+letter.

OK, I looked at the code.

In xterm.c, function handle_one_xevent, a KeyPress event is received,
with state == 0x06 (LockMask | ControlMask) and keycode == 52 (<AB01>
according to xkb/keycodes/evdev). Then, XmbLookupString is called on
this event, producing keysym == 0x5a ('Z') and storing a single 0x1a
character to copy_bufptr. The latter is ignored because the “if
(keysym >= 32 && keysym < 128)” branch is taken, producing an event
{kind: ASCII_KEYSTROKE_EVENT, code: 0x5a, modifiers: ctrl_modifier}.
The LockMask bit is lost at this point.

Then, under the “done:” label, the kbd_buffer_store_event_hold
function from keyboard.c is called, which in turn calls
make_ctrl_char, which sees 0x5a and sets the shift_modifier.

After this, no further processing, in Lisp or in C, can detect that
the Shift key was not in fact pressed.


The problem stems from the concept that keyboard input is a stream of
(extended) characters and any modifier keys just add modifier bits to
those characters. I do not think it can be fixed or worked around
without a significant rethinking of the input model.


This is unfortunate because, as a user, I expect Caps Lock to only
affect character input, not command bindings. As it is, turning on
Caps Lock upsets any key bindings that involve Shift. This includes
cua-mode’s C-x and C-c, and any user-defined bindings (in my case,
C-S-z = redo and C-S-u = insert-char).

Related: When I switch XKB groups (e.g. activate Russian layout), I
lose all C-letter and M-letter bindings, because they then produce
Cyrillic letters with the respective modifiers. E.g. with US English
QWERTY as primary and Russian ЙЦУКЕН as secondary, pressing Ctrl+W
produces C-ц instead of C-w. I work around this with an ugly
key-translation-map hack.