I know that has been already reported in #2522, but I'd like to bring it up again, as I believe the severity of the issue is undervalued.
I can understand the argument of having of different mapping for Ctrl+key and Alt+key combinations non-QWERTY latin layouts, but for non-latin (e.g. Cyrillic layouts), the experience is currently broken:
- It's really hard to use command line (e.g. there's no Ctrl+A to go to the beginning of the line, and Ctrl+W to delete a word)
- It's not possible to do auto-completion in vim (E.g. Ctrl+N, Ctrl+X), or "find next" (Alt+N), or many other combinations.
- Emacs is totally unusable (try it)
- Switching the layout back and forth just to type a control key is a very bad experience (as you may imagine).
Also unlike the non-QWERTY Latin layouts where keys are remapped (which is debatable, but I understand the point), for the case of Cyrillic, those combinations don't send any sequences at all, so this behavior just removes the functionality, not replaces it with something "more correct".
Describe the bug
When the current layout is cyrillic, Control key combinations (Ctrl+W, Ctrl+A, etc) don't work.
To Reproduce
Steps to reproduce the behavior:
- Select non-latin keyboard layout, e.g. Russian with:
setxkbmap -option grp:switch,grp:caps_toggle,grp_led:caps us,ru
- Use Caps lock to switch between layouts
- Try using Ctrl keys to navigate, e.g. Ctrl+A to go to the beginning of bash line, or try use auto-completion in bash, or try using emacs, or any other editor.
Actual behavior
Ctrl+ key combinations don't work
Expected behavior
Ctrl+ key combinations work
$ kitty --debug-config
kitty 0.19.1 created by Kovid Goyal
Linux cremator 5.9.6-arch1-1 #1 SMP PREEMPT Thu, 05 Nov 2020 21:00:46 +0000 x86_64
Arch Linux \r (\l)
LSB_VERSION=1.4
DISTRIB_ID=Arch
DISTRIB_RELEASE=rolling
DISTRIB_DESCRIPTION="Arch Linux"
Loaded config files: /home/crem/.config/kitty/kitty.conf
Running under: X11
Config options different from defaults:
background Color(red=18, green=38, blue=55)
bold_font JetBrains Mono Bold
color1 Color(red=255, green=0, blue=0)
color10 Color(red=59, green=207, blue=29)
color11 Color(red=236, green=200, blue=9)
color12 Color(red=85, green=85, blue=255)
color13 Color(red=255, green=85, blue=255)
color14 Color(red=106, green=227, blue=249)
color2 Color(red=55, green=221, blue=33)
color3 Color(red=254, green=228, blue=9)
color4 Color(red=20, green=96, blue=210)
color5 Color(red=255, green=0, blue=93)
color6 Color(red=0, green=187, blue=187)
color7 Color(red=187, green=187, blue=187)
color8 Color(red=84, green=84, blue=84)
color9 Color(red=244, green=13, blue=23)
cursor Color(red=240, green=203, blue=9)
font_family JetBrains Mono
font_size 9.0
foreground Color(red=255, green=255, blue=255)
italic_font JetBrains Mono Italic
selection_background Color(red=24, green=52, blue=79)
selection_foreground Color(red=181, green=181, blue=181)
shell /usr/bin/fish
I know that has been already reported in #2522, but I'd like to bring it up again, as I believe the severity of the issue is undervalued.
I can understand the argument of having of different mapping for Ctrl+key and Alt+key combinations non-QWERTY latin layouts, but for non-latin (e.g. Cyrillic layouts), the experience is currently broken:
Also unlike the non-QWERTY Latin layouts where keys are remapped (which is debatable, but I understand the point), for the case of Cyrillic, those combinations don't send any sequences at all, so this behavior just removes the functionality, not replaces it with something "more correct".
Describe the bug
When the current layout is cyrillic, Control key combinations (Ctrl+W, Ctrl+A, etc) don't work.
To Reproduce
Steps to reproduce the behavior:
setxkbmap -option grp:switch,grp:caps_toggle,grp_led:caps us,ruActual behavior
Ctrl+ key combinations don't work
Expected behavior
Ctrl+ key combinations work