Ignoring keyboard modes for key chords

Ignoring keyboard modes for key chords

[Yuri Khan]

Hello all,

I stumbled on a patch by Dima Kogan[^#24456] which partially fixes an
important usability bug. Namely, on some platforms and toolkits,
pressing C-s while Caps Lock is on produced C-S. That is, a persistent
mode (Caps Lock) affects the base character to which transient
modifiers (C-, M- and possibly s- and h-) are applied.

[^#24456]: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=24456

How can we generalize this to multiple keyboard layouts?


## Background

Users who need to enter text in more than one alphabet (e.g. Latin and
Cyrillic, or Latin and Greek, or Latin and Hebrew) use multiple
keyboard layouts. Typically, there is a small number of layouts (2 or
3) installed simultaneously; one of these is regarded as primary and
is the default layout that gets activated after login and possibly in
other circumstances. The user switches between installed layouts with
a special desktop-wide key binding, such as Ctrl+Shift, Alt+Shift, or
Cmd+Space. In this regard, a layout behaves as a persistent mode.


## Problem statement

On at least some platforms and toolkits (observed on
Gtk+/X11/GNU/Linux), pressing a key chord such as C-s while a
non-Latin keyboard layout is active produces an event with the correct
modifiers but the base character interpreted according to that layout.
For example:

    $ setxkbmap en,ru , grp:ctrl_shift_toggle
    $ emacs -Q
    Ctrl+Shift
    Ctrl+s
    ⇒ C-ы is undefined


## Expected behavior

The general expectation among users is that the base key in a chord
should be interpreted according to the installed Latin layout. In the
above example, Ctrl+s should produce C-s, even though the Russian
layout is active.

In case there are more than one Latin layout, the primary layout should be used.


## Non-solutions

This issue has been brought up in the past on Emacs lists. A common
suggestion is to use Emacs input methods, e.g. the C-\ binding. If one
is careful to only use that in Emacs and not the windowing system’s
facilities, the problem is avoided.

This is a non-solution because the user then faces increased cognitive
burden by having to remember to switch layouts differently in Emacs
and the rest of the system.


## Complications

1: I expect the problem manifests differently depending on the
operating system, windowing system, toolkit and possibly desktop
environment.

2: It may not be possible to confidently detect layout-based
reinterpretation after the fact. For example, using the above en,ru
example, pressing C-/ while the Russian layout is active will generate
a C-. event.

Re: Ignoring keyboard modes for key chords

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Sun, 16 Oct 2016 12:45:52 +0600
> 
> On at least some platforms and toolkits (observed on
> Gtk+/X11/GNU/Linux), pressing a key chord such as C-s while a
> non-Latin keyboard layout is active produces an event with the correct
> modifiers but the base character interpreted according to that layout.
> For example:
> 
>     $ setxkbmap en,ru , grp:ctrl_shift_toggle
>     $ emacs -Q
>     Ctrl+Shift
>     Ctrl+s
>     ⇒ C-ы is undefined

This problem doesn't exist on MS-Windows, FWIW.

> ## Expected behavior
> 
> The general expectation among users is that the base key in a chord
> should be interpreted according to the installed Latin layout. In the
> above example, Ctrl+s should produce C-s, even though the Russian
> layout is active.

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.

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-ы
  . it will not solve the case of multi-key sequences, such as
    "C-x ы"
  . 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

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?

> 2: It may not be possible to confidently detect layout-based
> reinterpretation after the fact. For example, using the above en,ru
> example, pressing C-/ while the Russian layout is active will generate
> a C-. event.

Isn't there an X event already that announces the keyboard layout
change?  There is such an event on Windows, and Emacs already includes
support for it, albeit only in the Windows build.

Re: Ignoring keyboard modes for key chords

[Yuri Khan]

On Sun, Oct 16, 2016 at 2:09 PM, Eli Zaretskii <eliz@gnu.org> 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.

Re: Ignoring keyboard modes for key chords

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Sun, 16 Oct 2016 14:52:02 +0600
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> On Sun, Oct 16, 2016 at 2:09 PM, Eli Zaretskii <eliz@gnu.org> 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?

Emacs is not a GTK application.  It just uses some of the GTK
features, treating GTK as a fancy toolkit for various decorations.

> > 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:

That's not the solution I had in mind.  I had in mind a solution that
would send to Emacs C-s no matter what's the current keyboard
language, without Emacs having to do anything.

> 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.

Yes, indeed.

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

But the solution will almost certainly be different.

Anyway, I won't object to patches which would produce this effect, but
I think this shouldn't be high on our priority scale.