Re: New key binding syntax

[Alexandre Garreau]

Le mardi 2 novembre 2021, 04:54:17 CET Richard Stallman a écrit :
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>   > Have a look at the kbd-valid-p doc string on the current trunk for a
>   > definition.
> 
> I've included that text below, because now is the time
> for people to look at and comment on it.
> 
> Should the syntax Emacs adopts for the next 20 years be this one?
> This one with some changes?

What wasn’t that ever normalized/documented? it always seemed to be that 
“kbd” was the standard way of specifying keystrokes… was it just informal?

> Any other proposal?

I always wondered: if one day emacs was to allow to gracefully support 
key-chords [0] (that is, using any key other as a “modifier”, so that you 
could press a and b at the same time and it would be a special keystrokes, 
which makes expressivity of keystrokes increase factorially with length 
instead of exponentially), at least in certain configurations.

That feature (actually, dirty hack, for now, but the author consider emacs 
to be misdesigned apparently, according implementation notes) is even 
advertised on emacs’ webpage through the emacsrock serie [1]

The extension currently looks dirty, and isn’t integrated into kbd at all, 
but if it were to be, should Control+Meta+a+b (a and b being the lowercase 
letters a and b, not variables) be specified “C-M-ab” or “C-M-a-b”: the 
most intuitive would be the later, because - aquires some kind of semantic 
of “at the same time” (which most of other programs describe with a “+” 
nowadays, which is less confusing, so C-M-a-b would be Control+Meta+A+B 
(they also usually are case-insensitive, while emacs case-sensitive 
afaiu)), but if a keyboard layout included a “uppercase A” key, and one 
used uppercase letters in keystrokes, then it would be impossible to say 
C-A-B” without A being understood as Alt (and using a rigid order for 
specifying modifiers in order to distinguish them from else looks 
confusing).  C-M-ab is somewhat less logical but wouldn’t break the 
existing interpretation.  Could a definition allowing a such form (although 
saying it is by default unsupported) be considered?

Furthermore, I would be in favor (and maybe that could help people to 
switch more seemlessly to emacs) to relax that syntax (as long as it is 
not ambiguous) and tweak it per-configuration (so when a keystroke is 
displayed, such as in minibuffer, in *Help* etc. it could be displayed 
differently), such as to for instance allow using a + character instead of 
a - (which is now more widespread and easily understood, although I find 
the - more sober hence more beautiful, but that’s maybe personal 
conservatism linked to habitude, and then it would be nice to only keep 
that as a personal configuration), or sometimes specifying the modifiers 
names all written (such as “Meta-” instead of “M-”: currently that causes 
no ambiguity as “Meta-” is translated as such and has no meaning afaik) if 
the user wishes to, so that for instance config/UI looks more 
understandable to outsiders and newcomers (I have to note that *merely 
looking* at a used (habituated? how to say?) user of emacs is per se an 
important form of advertisement of emacs (it makes people curious, it 
looks fast, it looks confident, it works great))

> If we use this syntax, the text we use to define it in the Emacs Lisp
> Ref Manual should cover valid cases not mentioned in this text.
> We don't use them in normal Emacs bindings, but they are valid
> so they should be documented.

could it be possible for keystrokes as displayed by a manual to be 
configurable? such as having (maybe that’s already the case) semantical 
markup for those, so that at compilation, or at visualisation (if the 
software supports it) they can be displayed differently, such as as I 
proposed.

> ======================================================================
> Say whether KEYS is a valid `kbd' sequence.
> A `kbd' sequence is a string consisting of one and more key
> strokes.  The key strokes are separated by a space character.

I agree with what was said that this should be a partitive “whitespace”, 
not an absolute space character.  That could be translated to a canonical 
form with only one space character later (after all differences in 
whitespace are irrelevant out of context).

> Each key stroke is either a single character, or the name of an
> event, surrounded by angle brackets.  In addition, any key stroke
> may be preceded by one or more modifier keys.  Finally, a limited
> number of characters have a special shorthand syntax.

> Here's some example key sequences.
> 
>   \"f\"           (the key 'f')
>   \"S o m\"       (a three key sequence of the keys 'S', 'o' and 'm')
>   \"C-c o\"       (a two key sequence of the keys 'c' with the control
> modifier and then the key 'o')
>   \"H-<left>\"    (the key named \"left\" with the hyper modifier)
>   \"M-RET\"       (the \"return\" key with a meta modifier)
>   \"C-M-<space>\" (the \"space\" key with both the control and meta
> modifiers)



> Modifiers have to be specified in this order:
> 
>    A-C-H-M-S-s
> 
> which is
> 
>    Alt-Control-Hyper-Meta-Shift-super

What happens otherwise? an error? or, more gracefully, a translation? that 
could be a canonical order (that’s just alphabetical right?)