Re: [External] : New key binding syntax

[Alexandre Garreau]

Le jeudi 18 novembre 2021, 15:59:28 CET Yuri Khan a écrit :
> On Thu, 18 Nov 2021 at 21:36, Alexandre Garreau <galex-713@galex-713.eu> 
wrote:
> > > Keys are not ASCII characters.
> > 
> > They can be related.  You could set up a keymap layout where each key
> > is capital, and pressing shift makes them lowercase, at the opposite
> > of the normal working, or even something more weird.
> 
> Hey, millions of people

I’d say millions if it was less than 10 millions, here I’d rather say 
hundreds of millions, or tenths of billion

> deal daily with layouts where pressing the key
> Q yields the character й.

Then it’s the key Й, not the key Q.  Qwerty is not in any way “more basic” 
or “more low level” than Йцукен.  What’s lower level are scancode 
(arbitrary numbers, depending of position on keyboard + whether it’s 
pressed or released + history), translated to keycodes (not depending of 
whether it’s pressed or released, used by keymap layouts definitions), 
translated, by a given keyboard layout (be it US qwerty, US dvorak, 
programmer dvorak, standard russian йцукенп, polyglot reactionary йцукен 
(what I use), french azerty, belgian azerty, french bépo, german qwertz, 
swiss qwertz, etc.) to keysyms (which *are* characters, such as Q or Й, 
most of the time, but also can be other actions such as XF86AudioPlay)

> In Emacs, one has to mess with
> function-key-map so й translates to q which buries Dired.

What about quail?

Imho, when you are too often used to use a non-latin layout, using an 
input-method may be useful, as these will translate keys to write text, 
but not to enter keybindings

> In an ideal
> world, Dired would bind not the character q but the key Q, and it
> would just work no matter the layout.

You cannot do that.  There is no “key Q” independent from a character, 
whatever the layout is.  So either you would use quail and/or input-method 
to parametrize how emacs would translate keys, either (and that has been 
stated as desirable but complex in the past) emacs would use lower-level 
functions of terminal/X (just as, say, i3wm does) to use keycodes… which 
are *not* related to keys, hence are by default not related to letters/
characters, but only to a position on keyboard, so they *cannot* be 
mnemonic just as emacs does by default… or then, you would have to 
*choose* manually one layout to take your key positions from, and 
translate keysyms to keycodes… which is pretty unusual and esoteric, but 
could be done as well from a keymap layout definition (find yours in 
something such as /usr/share/X11/xkb/symbols/ru)