Current keyboard layout (language) shouldn't affect keybindings

[RuRo]

As the title says, hotkeys should work the same, no matter, what keyboard layout is selected. For example, if I have the en-US layout enabled, pressing Ctrl+V pastes the clipboard contents. But if I switch to some other layout, like ru-RU which doesn't have the same letter, where the V key is physically located on the keyboard and press the same physical key combination, the Russian letter 'м' is inserted instead of the clipboard contents.

DrRacket: v7.9
OS: Manjaro Linux (basically Arch Linux)
DE: KDE Plasma 5.20.5

If you need any extra info, feel free to ask.

[Metaxal]

What if the layout does have the same letter at a different place?

For example, I often use a variant of the French layout on a UK keyboard, and I expect Ctrl-V to paste, where V is the letter I press to print V (which is different from where the V is placed on my keyboard).

[RuRo]

where V is the letter I press to print V (which is different from where the V is placed on my keyboard)

@Metaxal I don't really understand, what are you trying to say here.

---

Just to be clear, my issue is not about Physical keyboard layouts (QWERTY vs QWERTZ vs AZERTY), but about Virtual/Language layouts (en-US vs ru-RU). Here is a more concrete example.

The standard Russian physical keyboard looks something like this:

Both the red and black letters are actually physically printed on the key caps. The user is then able to switch between the languages by pressing some key combination (commonly Alt+Shift). The currently selected language is shown as a small icon in the task bar.

I can type "Hello", if I have the en-US layout selected, but if I press the same physical keys while the ru-RU layout is selected, I will type "Руддщ" instead.

As you can see, there is no red (Cyrillic) letter V and the key which has the black (Latin) letter V has the Cyrillic letter М. The correct behaviour is for shortcuts to perform exactly the same action, ignoring which Virtual/Language layout is currently selected and only considering which physical key is pressed. This is how hotkeys already work in 99.999% of applications in both Windows and Linux, but for some reason it doesn't work in DrRacket on Linux.

[rfindler]

This is probably something going wrong at the racket/gui layer as that's what's taking the os-provided keyboard input and turning it into callbacks that DrRacket sees.

@RuRo What happens if you run racket -l tests/gracket/showkey and try some of the non-working keystrokes? (Depending on how you've installed racket you may need to run raco pkg install gui-test first, so try that if you get an error that starts with standard-module-name-resolver: collection not found for module path: (lib "tests/gracket/showkey").

[RuRo]

Pressing Ctrl+V in racket -l tests/gracket/showkey:

In en-US layout (works)

``` 1 KEY: control rel-code: press other-codes: (control control control control) mods: 2 KEY: "v" = ASCII 118 rel-code: press other-codes: ("V" = ASCII 86 #f #f "V" = ASCII 86) mods: CTL 3 KEY: release rel-code: "v" = ASCII 118 other-codes: ("V" = ASCII 86 #f #f "V" = ASCII 86) mods: CTL 4 KEY: release rel-code: control other-codes: (control #f #f control) mods: CTL ```

In ru-RU layout (doesn't work)

``` 1 KEY: control rel-code: press other-codes: (control control control control) mods: 2 KEY: "м" = ASCII 1084 rel-code: press other-codes: ("М" = ASCII 1052 #f #f "М" = ASCII 1052) mods: CTL 3 KEY: release rel-code: "м" = ASCII 1084 other-codes: ("М" = ASCII 1052 #f #f "М" = ASCII 1052) mods: CTL 4 KEY: release rel-code: control other-codes: (control #f #f control) mods: CTL ```

[Metaxal]

@RuRo Thanks for the clarification. Just to provide some more side information. This is my physical UK layout: This is my virtual (custom) layout:

When I press Ctl-v on my virtual layout, I expect to send a paste command and I do not expect to send a paste command when I press Ctl-., which corresponds to Ctl-v on my physical layout.

So if your Russian layout is considered a virtual layout, while your English layout is your physical layout, I have no idea how this difference in expectations is resolved usually.

But if you had a V (for some reason) on your (suddenly not so) Russian layout, wouldn't you expect pressing Ctrl-V on the virtual layout to send a paste command?

Edit: To be clear, I'm absolutely not suggesting that there is no issue! I'm just pointing out some difficulties in resolving this issue: DrRacket should not merely use the physical layout to know how to interpret the keybinding.

[RuRo]

@Metaxal

But if you had a V (for some reason) on your (suddenly not so) Russian layout, wouldn't you expect pressing Ctrl-V on the virtual layout to send a paste command?

No, I wouldn't expect that. In my mind, hotkeys are supposed to be remembered with motor skills (your fingers remember how to move, to perform an action) and not with "text" commands (you press a modifier key and then type some characters).

The second approach would mean that: 1) You effectively need to spend twice the effort to get a hotkey into your muscle memory. (or switch layouts every time you want to perform an action) 2) You need to always actively remember, which layout you currently have selected.

Also, consider how this affects the ergonomics of the hotkeys, which were intended to be located near each other. (undo-cut-copy-paste or something like vim's hjkl)

Does the behaviour you propose currently work in other applications? Because in my experience, all applications use the behaviour, I am describing.

[Metaxal]

[...] Also, consider how this affects the ergonomics of the hotkeys, which were intended to be located near each other. (undo-cut-copy-paste or something like vim's hjkl)

I see. Indeed, for a 'double' layout like yours, this certainly makes sense. In my case, I only use a single layout (the virtual one), and not the physical layout at all. For example, if I have to work on a German laptop, I can just load my virtual layout and not be bothered with the German keys at all, and not have to learn anything new (muscle memory as you mention).

Does the behaviour you propose currently work in other applications? Because in my experience, all applications use the behaviour, I am describing.

Yes, my virtual layout works in every application. My guess is that there is something special about 'double' layouts that must be detected and dealt with, but I have no idea how this works.

[RuRo]

@Metaxal

In my case, I only use a single layout (the virtual one), and not the physical layout at all.

Then couldn't you just set the physical keyboard layout to the one, that you always use? It's not like the OS can inspect, what is printed on the actual key caps.

I'm am not 100% sure, but I was under the impression, that the "physical" layout is simply determined by whatever layout is first in the list.

[Metaxal]

In my case, I only use a single layout (the virtual one), and not the physical layout at all.

Then couldn't you just set the physical keyboard layout to the one, that you always use? It's not like the OS can inspect, what is printed on the actual key caps.

I'm am not 100% sure, but I was under the impression, that the "physical" layout is simply determined by whatever layout is first in the list.

Yes, and—although I don't clearly understand how things work here—it seems to me that this is also what is happening when you press Alt+Shift: you change the master layout to Russian and the English layout becomes invisible to DrRacket, as you can see in the showkey tests.

So the mystery to me is how other applications manage to handle this situation correctly.