From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alexandre Garreau Newsgroups: gmane.emacs.devel Subject: Re: New key binding syntax Date: Tue, 02 Nov 2021 17:22:16 +0100 Message-ID: <52799093.VymdKvaGTe@galex-713.eu> References: <20211004081724.6281.11798@vcs0.savannah.gnu.org> <87v91dnsxg.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26230"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org, rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 02 17:27:56 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mhwdg-0006dM-0w for ged-emacs-devel@m.gmane-mx.org; Tue, 02 Nov 2021 17:27:56 +0100 Original-Received: from localhost ([::1]:59100 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mhwdf-0007wK-3h for ged-emacs-devel@m.gmane-mx.org; Tue, 02 Nov 2021 12:27:55 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58484) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mhwYg-0004t9-9r for emacs-devel@gnu.org; Tue, 02 Nov 2021 12:22:46 -0400 Original-Received: from portable.galex-713.eu ([2a00:5884:8305::1]:55144 helo=galex-713.eu) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mhwYa-0001pQ-KI; Tue, 02 Nov 2021 12:22:44 -0400 Original-Received: from gal by galex-713.eu with local (Exim 4.92) (envelope-from ) id 1mhwYC-0003Wr-RN; Tue, 02 Nov 2021 17:22:16 +0100 In-Reply-To: Received-SPF: pass client-ip=2a00:5884:8305::1; envelope-from=galex-713@galex-713.eu; helo=galex-713.eu X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:278502 Archived-At: Le mardi 2 novembre 2021, 04:54:17 CET Richard Stallman a =C3=A9crit : > [[[ 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. ]]] >=20 > > Have a look at the kbd-valid-p doc string on the current trunk for a > > definition. >=20 > I've included that text below, because now is the time > for people to look at and comment on it. >=20 > Should the syntax Emacs adopts for the next 20 years be this one? > This one with some changes? What wasn=E2=80=99t that ever normalized/documented? it always seemed to be= that=20 =E2=80=9Ckbd=E2=80=9D was the standard way of specifying keystrokes=E2=80= =A6 was it just informal? > Any other proposal? I always wondered: if one day emacs was to allow to gracefully support=20 key-chords [0] (that is, using any key other as a =E2=80=9Cmodifier=E2=80= =9D, so that you=20 could press a and b at the same time and it would be a special keystrokes,= =20 which makes expressivity of keystrokes increase factorially with length=20 instead of exponentially), at least in certain configurations. That feature (actually, dirty hack, for now, but the author consider emacs= =20 to be misdesigned apparently, according implementation notes) is even=20 advertised on emacs=E2=80=99 webpage through the emacsrock serie [1] The extension currently looks dirty, and isn=E2=80=99t integrated into kbd = at all,=20 but if it were to be, should Control+Meta+a+b (a and b being the lowercase= =20 letters a and b, not variables) be specified =E2=80=9CC-M-ab=E2=80=9D or = =E2=80=9CC-M-a-b=E2=80=9D: the=20 most intuitive would be the later, because - aquires some kind of semantic= =20 of =E2=80=9Cat the same time=E2=80=9D (which most of other programs describ= e with a =E2=80=9C+=E2=80=9D=20 nowadays, which is less confusing, so C-M-a-b would be Control+Meta+A+B=20 (they also usually are case-insensitive, while emacs case-sensitive=20 afaiu)), but if a keyboard layout included a =E2=80=9Cuppercase A=E2=80=9D = key, and one=20 used uppercase letters in keystrokes, then it would be impossible to say=20 C-A-B=E2=80=9D without A being understood as Alt (and using a rigid order f= or=20 specifying modifiers in order to distinguish them from else looks=20 confusing). C-M-ab is somewhat less logical but wouldn=E2=80=99t break the= =20 existing interpretation. Could a definition allowing a such form (although= =20 saying it is by default unsupported) be considered? =46urthermore, I would be in favor (and maybe that could help people to=20 switch more seemlessly to emacs) to relax that syntax (as long as it is=20 not ambiguous) and tweak it per-configuration (so when a keystroke is=20 displayed, such as in minibuffer, in *Help* etc. it could be displayed=20 differently), such as to for instance allow using a + character instead of= =20 a - (which is now more widespread and easily understood, although I find=20 the - more sober hence more beautiful, but that=E2=80=99s maybe personal=20 conservatism linked to habitude, and then it would be nice to only keep=20 that as a personal configuration), or sometimes specifying the modifiers=20 names all written (such as =E2=80=9CMeta-=E2=80=9D instead of =E2=80=9CM-= =E2=80=9D: currently that causes=20 no ambiguity as =E2=80=9CMeta-=E2=80=9D is translated as such and has no me= aning afaik) if=20 the user wishes to, so that for instance config/UI looks more=20 understandable to outsiders and newcomers (I have to note that *merely=20 looking* at a used (habituated? how to say?) user of emacs is per se an=20 important form of advertisement of emacs (it makes people curious, it=20 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=20 configurable? such as having (maybe that=E2=80=99s already the case) semant= ical=20 markup for those, so that at compilation, or at visualisation (if the=20 software supports it) they can be displayed differently, such as as I=20 proposed. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 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 =E2=80=9Cwhitesp= ace=E2=80=9D,=20 not an absolute space character. That could be translated to a canonical=20 form with only one space character later (after all differences in=20 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. >=20 > \"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-\" (the key named \"left\" with the hyper modifier) > \"M-RET\" (the \"return\" key with a meta modifier) > \"C-M-\" (the \"space\" key with both the control and meta > modifiers) > Modifiers have to be specified in this order: >=20 > A-C-H-M-S-s >=20 > which is >=20 > Alt-Control-Hyper-Meta-Shift-super What happens otherwise? an error? or, more gracefully, a translation? that= =20 could be a canonical order (that=E2=80=99s just alphabetical right?)