Re: Ignoring keyboard modes for key chords

[Yuri Khan]

On Sun, Oct 16, 2016 at 2:09 PM, Eli Zaretskii <address@hidden> wrote:

> Why is this expected to be solved by Emacs, and not by some option on
> the level of the OS keyboard driver?  I'm guessing that doing this in
> Emacs would require messing with low-level keyboard interfaces,
> something Emacs is better off without, IMO.

Because none of the other Gtk+ applications exhibit the problem?

> Moreover, the expected behavior, if implemented in Emacs, will have at
> least 2 disadvantages:
>
>   . it will disallow keystrokes with modifiers that use non-ASCII
>     characters, such as C-ы

Does anybody actually want or use this?

>   . it will not solve the case of multi-key sequences, such as
>     "C-x ы"

It would be nice to solve these, too. And single-key non-modified keys
such as those in dired and ibuffer.

>   . it may not be possible at all on a TTY, or at least I expect the
>     problems there to be more prominent, since on many terminals M-x
>     is sent to Emacs as "ESC x", which are 2 keys

Yes. The shoehorning of keystrokes into a character stream model is a
fundamental limitation of the current TTY protocol. It is most
unfortunate but it should not discourage us from solving a problem on
toolkit where it can be solved.


> So it could only be a partial solution at best.
>
> I would expect solutions for this to exist already for GNU/Linux and
> other free OSes, isn't that so?  If such solutions exist, why not use
> them instead?

Here is the output of xev(1) when pressing C-s with US and Russian
layouts installed, Russian layout active:

    KeyPress event, serial 33, synthetic NO, window 0x2a00001,
        root 0x4b9, subw 0x0, time 292017728, (-1382,-332), root:(449,621),
        state 0x2004, keycode 39 (keysym 0x73, s), same_screen YES,
        XLookupString gives 1 bytes: (13) ""
        XmbLookupString gives 1 bytes: (13) ""
        XFilterEvent returns: False

No traces of ы here.

However, a simple Gtk+3 program which listens for keyboard events and
dumps them to terminal shows me this:

    {'group': 1,
     'string': 'ы',
     'length': 2,
     'time': 293166884,
     'type': <enum GDK_KEY_PRESS of type Gdk.EventType>,
     'sent_event': 0,
     'keyval': '0x6d9',
     'is_modifier': 0,
     'hardware_keycode': 39,
     'state': '0x2004',
     'window': <GdkX11.X11Window object at 0x7fc32976a8b8
(GdkX11Window at 0x1fb8450)>}

According to <gdk/gdkkeysyms.h>, keyval 0x6d9 is called
GDK_KEY_Cyrillic_yeru. And looking at the hardware_keycode is
suboptimal because that would presumably break Dvorak, Colemak and
AZERTY.

However, Gtk also has a notion of accelerators, which is the mechanism
most Gtk programs use to bind shortcut keys to UI commands. I coded a
test program which creates a window and a signal, adds Ctrl+s as an
accelerator on that window that invokes that signal, and handles the
signal by printing “Hello” on the standard output. The handler gets
invoked when I press Ctrl+s no matter which layout is active.

So, the root cause of the issue is that Emacs is not integrated with
Gtk’s accelerator system. And it’s not clear if it could, while
staying cross-toolkit.

I also wondered whether the issue is Gtk-specific. It’s not;
emacs24-lucid exhibits the same behavior.