bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#45347: Feature request: key positions for shortcuts instead of lette


From: Juri Linkov
Subject: bug#45347: Feature request: key positions for shortcuts instead of letters in Emacs
Date: Mon, 21 Dec 2020 10:41:28 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu)

merge 43830 45347
thanks

Thanks for your request.  Please see the recent discussion about this problem in
https://debbugs.gnu.org/43830

The latest idea there was to add scancodes to the event structure.
Then it should be possible to bind commands to scancodes,
or at least to translate scancodes to Emacs keys.

> Currently, to type (at least) Cyrillic other than English in Emacs, you can
> switch your keyboard layout in X.Org to Russian or Ukrainian or any other
> language that has Cyrillic lettters. However, keybindings don't work. If I
> type "C-ф" (ф is on the home row, pinky finger), it does not register as
> "C-a". A lot of people have to use packages like reverse-im.el to partially
> fix the issue. It uses Quail maps for keyboard layouts.
>
> But reverse-im has lots of issues that can't be fixed without changing the
> Emacs core. If you configure it to use russian-typewriter map, switch to
> russian-typewriter layout in X.Org and type C-2 on it, it registers as C--,
> because on the Russian Typewriter layout 2 is actually a hyphen. Emacs
> doesn't know if it's a hyphen on the English layout or a hyphen on the
> Russian layout. If you're using a not-so-popular language (such as Kazakh,
> which is what I happen to use), you have to make a Quail map from scratch.
> If you're typing in German, C-S-7 will undo instead of whatever C-S-7 does
> in English. On German QWERTZ layout, the letter Z is in the same place as
> Y, thus the user has to remember different positions for Z and Y, because
> German has them swapped and it depends on the language currently chosen.
> French people with AZERTY have this issue, too. If you're using English
> Dvorak, all the letters in other languages will translate to English
> QWERTY, and you have to make a Quail map for all languages so that they
> translate to Dvorak. Shortcuts that use a single key (like C-x e or of
> Evil/Viper-mode/Boon/etc) won't work, because a single key will turn into a
> letter from an alternative alphabet. It affects everyone except people who
> only know English. Some suffer heavily (like me, I use Kazakh, Russian and
> English Dvorak), some suffer less (
>
> In my opinion, if the user uses X.Org or Wayland, Emacs has to record key
> positions instead of the letters that were input. X.Org has that, it's
> called a keycode. If you start xev, type the Tilde key on Russian and
> English, the keycode stays the same, although on Russian the letter typed
> is Ё instead of the tilde. Thus, Ctrl+keycode101 will always be
> Ctrl+keycode101, no matter the keyboard layout. All programs use this
> method. However, it's not perfect. On QWERTY and Dvorak, the keycodes are
> also the same. If we bind shortcuts to the keycodes only, all shortcuts on
> Dvorak will turn into QWERTY. A solution for this is parsing the "setxkbmap
> -query" command. It shows the languages (to the right of "layout" in the
> output) and its variants (empty means the default for the language). For
> example, English QWERTY and Russian Typewriter show this output:
>
>  
>
> layout: us,ru
> variant: ,typewriter
>  
> English Dvorak and RussianTypewriter show this output:
>  
> layout: us,ru
> variant: dvorak,typewriter
>  
> We should account for alternative keyboard layouts.
> Some people make their own keyboard layout variants that are not shipped
> with X.Org by default. I don't know how to deal with this, but all the
> other programs have the correct shortcuts on the Russian layout if you make
> your own variant...
>
> There are some modes that use a single keystroke without any modifiers as
> shortcuts (like dired, Viper-mode, Evil-mode). If the command ran from a
> single keystroke is not a self-insert-command, in my opinion, it should be
> converted from other language letter to an English letter for compatibility
> with these modes.
>
> There's a package called "key-chord.el". I don't know how to make it work,
> honestly, but maybe we can make a new function that maps to keycodes
> instead of letters, so that key-chord.el could write a simple patch that
> uses them?
>
> We also should make it a separate mode, so that people who rely on that
> behavior for custom shortcuts can turn it off.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]