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: Fri, 05 Nov 2021 10:13:11 +0100 Message-ID: <3412236.9QipagVtEG@galex-713.eu> References: <20211004081724.6281.11798@vcs0.savannah.gnu.org> <1763939.ehZidYVhZF@galex-713.eu> 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="11183"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Richard Stallman , Emacs developers To: Yuri Khan Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 05 10:14:15 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 1mivId-0002kt-A4 for ged-emacs-devel@m.gmane-mx.org; Fri, 05 Nov 2021 10:14:15 +0100 Original-Received: from localhost ([::1]:45952 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mivIb-0004dC-AI for ged-emacs-devel@m.gmane-mx.org; Fri, 05 Nov 2021 05:14:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60520) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mivHk-0003uX-02 for emacs-devel@gnu.org; Fri, 05 Nov 2021 05:13:20 -0400 Original-Received: from portable.galex-713.eu ([2a00:5884:8305::1]:46170 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 1mivHh-00042v-Vb; Fri, 05 Nov 2021 05:13:19 -0400 Original-Received: from gal by galex-713.eu with local (Exim 4.92) (envelope-from ) id 1mivHc-0001I8-29; Fri, 05 Nov 2021 10:13:12 +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:278752 Archived-At: Le vendredi 5 novembre 2021, 09:56:26 CET Yuri Khan a =C3=A9crit : > On Fri, 5 Nov 2021 at 13:08, Alexandre Garreau =20 wrote: > > > The rollover behavior works entirely on the application side, where > > > the OS and the GUI toolkit send events like =E2=80=9Cthe key at posit= ion > > > AB02 > > > was pressed while the left Alt is down; by the way, the character > > > for > > > this key in the current layout is x=E2=80=9D. If the application reac= ts to > > > key > > > press and autorepeat events and takes the character and modifiers > > > from > > > them immediately, the =E2=80=9CAC01 down (char a), AB05 down (char b)= , AC01 > > > up > > > (char a), AB05 up (char b)=E2=80=9D sequence results in an =E2=80=9Ca= then b=E2=80=9D text > > > input. But some applications (notably games) just track the whole > > > bit > > > array of keys. > >=20 > > But what happens after 7 consecutive down on a typical keyboard then? >=20 > Technically what happens in that highly theoretical example depends on > the firmware implementation; in the USB protocol, there is provision > for the keyboard reporting =E2=80=9Cthe user held down so many keys I can= =E2=80=99t > accurately report them all=E2=80=9D. so it=E2=80=99s like a down, b down, =E2=80=A6, f down=E2=80=A6 and then un= til I release any key=20 between a and f, if I press down =E2=80=9Cg=E2=80=9D, the keyboard won=E2= =80=99t say anything to=20 the application/OS? > > why this limitation since each key succeeds the previous one? >=20 > Each key does not =E2=80=9Csucceed=E2=80=9D the previous one. Keyboards a= re not only > used for text input but also for gaming and (rarely, with advanced > users) chord input, and they must be able to report at least a few > keys held down simultaneously, wdym by =E2=80=9Csimultaneously=E2=80=9D? =E2=80=9Cclose enough in time of = pressing=E2=80=9D? or =E2=80=9Cwhile=20 the others haven=E2=80=99t been released yet=E2=80=9D? > and the exact moment they are released. > In a game, it=E2=80=99s not an unusual situation that you hold down one k= ey to > crouch, another to keep moving (crawling?) forward, and a third one to > turn left or right, while periodically pressing a fourth key to fire. > If the keyboard reports the release too early, you stand back up, and > your enemies notice you. I know that, and actually the best usage of key chords, key sequences and=20 combos I=E2=80=99ve seen is indeed in FPSes. > The limitation is about the keyboard state report having a manageable > size. With this particular format, the 8 modifiers are reported as a > bit mask in a single byte, then there is a mostly reserved byte, then > 6 bytes contain the codes of keys currently held down. what? I thought the usb kbd firmware worked by sending events that=20 triggered interruptions, not that it stored keystate itself :o I thought=20 keystate was saved and registered application-side, with each event