Bug#1093056: xterm: Alt key combinations with non-Latin keyboard layouts don't send escape sequences in modifyOtherKeys mode 2
On Wed, Jan 15, 2025 at 01:30:19AM +0300, Ivan Sorokin wrote: > > Package: xterm > Version: 396-1 > > When modifyOtherKeys is set to mode 2 in xterm, pressing the Alt key in > combination with letters on a non-Latin keyboard layout does not produce any > escape sequences or characters. This makes it impossible to bind these key > combinations to specific actions within applications running inside xterm. > > Expected behavior: When modifyOtherKeys -specific sequence cannot be > generated, it should send an escape character followed by the corresponding > Unicode character, mirroring the behavior observed when modifyOtherKeys is > disabled (mode 0). > > Current behavior: No escape sequence or character is sent when Alt is > combined with letters in non-Latin keyboard layouts if modifyOtherKeys is set > to 2. > > Steps to reproduce: > * > Configure a non-Latin keyboard layout (e.g., Russian, Greek, etc.). xterm's using the X keyboard configuration, as described here https://invisible-island.net/xterm/modified-keys.html https://github.com/ThomasDickey/xterm-snapshots/blob/master/vttests/modify-keys.pl That's not Unicode as such, but is oriented to things that have a keysymbol. You might be encountering a limitation there - some keyboard configurations don't map all of the keys (or even misconfiguring the keyboard in some way). Given the same information that the script uses, you could generate a table helping to see whether it's a key that doesn't get mapped. The bug report doesn't actually tell us what the keyboard configuration is. The output from localectl, for instance, would show what's configured. -- Thomas E. Dickey https://invisible-island.net signature.asc Description: PGP signature
Bug#1092890:
control: affects -1 kf6-bluez-qt kf6-kquickcharts
Processed:
Processing control commands: > affects -1 kf6-bluez-qt kf6-kquickcharts Bug #1092890 [libglx-mesa0] mesa: regression in 24.3: software rendering crashes on ppc64el with segmentation fault Added indication that 1092890 affects kf6-bluez-qt and kf6-kquickcharts -- 1092890: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1092890 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1093056: xterm: Alt key combinations with non-Latin keyboard layouts don't send escape sequences in modifyOtherKeys mode 2
Package: xterm Version: 396-1 When modifyOtherKeys is set to mode 2 in xterm, pressing the Alt key in combination with letters on a non-Latin keyboard layout does not produce any escape sequences or characters. This makes it impossible to bind these key combinations to specific actions within applications running inside xterm. Expected behavior: When modifyOtherKeys -specific sequence cannot be generated, it should send an escape character followed by the corresponding Unicode character, mirroring the behavior observed when modifyOtherKeys is disabled (mode 0). Current behavior: No escape sequence or character is sent when Alt is combined with letters in non-Latin keyboard layouts if modifyOtherKeys is set to 2. Steps to reproduce: * Configure a non-Latin keyboard layout (e.g., Russian, Greek, etc.). * Start xterm with modifyOtherKeys set to 2 (either through a resource file or command-line option). * Run showkey -a, press Alt in combination with various non-Latin letters. * Observe that no escape sequences or characters are output. This issue hinders the usability of xterm with non-Latin keyboard layouts when custom keybindings relying on Alt key combinations are desired (like in far2l project in which I contribute code from time to time). A fix would greatly improve accessibility and allow users to fully leverage their keyboard's capabilities within xterm. FYI, releated issue in far2l issue tracker https://github.com/elfmz/far2l/issues/2628#issuecomment-2591151386
