From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Po Lu Newsgroups: gmane.emacs.devel Subject: Re: master 3b41141708: Expose the name of an event's input device to Lisp Date: Fri, 08 Apr 2022 19:31:28 +0800 Message-ID: <87o81bu7zj.fsf@yahoo.com> References: <164933858147.29834.15050766441005536059@vcs2.savannah.gnu.org> <20220407133623.9C209C009A8@vcs2.savannah.gnu.org> <87ee28xyg2.fsf@yahoo.com> <83ee28az95.fsf@gnu.org> <87fsmow1hz.fsf@yahoo.com> <83a6cway59.fsf@gnu.org> <87tub4uivu.fsf@yahoo.com> <83y20fakwn.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38276"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Apr 08 13:33:11 2022 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 1ncmrU-0009ln-Tg for ged-emacs-devel@m.gmane-mx.org; Fri, 08 Apr 2022 13:33:09 +0200 Original-Received: from localhost ([::1]:52002 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ncmrT-0004VO-H4 for ged-emacs-devel@m.gmane-mx.org; Fri, 08 Apr 2022 07:33:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33554) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ncmq6-0003c0-LS for emacs-devel@gnu.org; Fri, 08 Apr 2022 07:31:42 -0400 Original-Received: from sonic309-20.consmr.mail.ne1.yahoo.com ([66.163.184.146]:44969) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ncmq4-0006dy-AZ for emacs-devel@gnu.org; Fri, 08 Apr 2022 07:31:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649417497; bh=Nni6qr8eLWBqyi3kllrZxZOBUN7NjUlgNTjiWNmhHCQ=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=nHAEUZC8iyVT0Yj42MJLKK4mPIBOEqlQFJhIbNroAQCfIDjUybIol8oz/EzS3gBMtAKBgpn6rKBHMg3iPpdWHOUc6xHGXfz/dy/wIHwy04sRxL+25+EI0zCFAhDY2v6E3lIjordjYEKcR04nqSDGjrzpgJerjhrHeHkTEawOSglGqV/+Vn4UmcLESdQ6BPEcuxqweLC0hrEHUyqRCTKLZVXYqYXmgODEZfmggo0VgaRKMmFPKqJzWZ8XP8uEhmtD0NxqNltDd57hlRbV2XNCiPUy+ldxHaCW7r5FR8QERbidDmHOfO0mi6EjDrYHS/vz69XH28x8UVwoKC1YPJyhNA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649417497; bh=J3+8KreJ9pbAM+fAiehzHaYK3Pl0hMSi2qPaffIuaih=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=aaSZLJP6K7KfoD2mLVyy8kN8EhgeKvBziUohkoUqVWEj5rq7qu+muC4CmLnt1/bIUN/LSjIx8V3XHh1uwfB/j7LWH1XzL5gowTePVp9u/175NZl7vd1QnetnUlVXT0Apjx82nr0F+/zg8nplYVNUzLiD6ITRPCc/MRUuy1hCUw/nYpXjKli6KGN1srYqd4jlSG64sn6VpycClfgMyQEZwzm0VC53wit6Fruk3UST/YpGvJ82Sp01wyYHfRa4ZqglDeOFvXKw7VhxrShlayaEOUkks2eFMX5JIAQEeNrkPJzURM9s6E+4Y7OHjRr/1lRVPGhIMNlgLE/Re1Lwxrb/fQ== X-YMail-OSG: IISJz3YVM1m8DOVPn3l51VT.Dp8IXM9q1B0N2XugiXbRqqzNGLHZzd_6VO4Q2z5 z6ea159cvwlpF.0jKw5GQQA4bZ4DEubQ1GDbn6ijeO_.v2kcagVdIYnFYUuazQRV8WnTGgBaMhOd XCYLflg57I1j1JU6IlnhGR8L.4XeGz5BFNFyt5YF4WvmLP_1IE8CFpze4dUxjCNTeKGZb7M2nYkW SvQGO8l.KUT8mG_bwC.QVjqm1Hmeqj7WGS1SVuAmdM0mFYbedUIQkanGfYF1V4Cg_t24nG5kAW4b Ldm5se4Yan6fV0LrSiGmHfL9B5zzfX0AKpMdX8c99d5cShGVobz_sKdM5iR90LD9jKXRMS59GDNX jOm5NGbD7fNZzu9QErkkVfyxZbP7CTaX5eyuNevTY1pVAqt.yeIp5mbbIgGuXB0n7Lh8rf9E6mJq UEKvY9Y.nRdHcBQPY4fVlQ6I3JS8i86_PcmrbhI09xJ6jn4SVVOXnCkrW7FMSWtmcg6frI_kIYXr ST8RBBn6j0Seo201boJ9LKE9VXVe9KkuljuZhhpSosQ4Ns_5jNfMle_kTn0MAVsFYI.TFTCe5C13 vssSDnmZFi4gnUkc8m76Orw3RNrJTLqulKHbgQyxoTSoXJXOsk7eTmOQqQ9vn6Aqhc90THrc.UU8 g7_DLINjpS5nSkV1m0IV2Dr1li9Nz9NSBt6p_M.5oMou6XuZ90U37Ec2HU2C5VoxVzIN6bENx0nl feSASA6TokryZkEf.dejynIbL7OyzzSyFNt.1XHLy57e4T5sVljPt6Zfy1dwZV_XpqsbdB6kmFbS dAYeepJDAFabimd2AMuwWVlyGmvqFR3xv18Xhr2LBN X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.ne1.yahoo.com with HTTP; Fri, 8 Apr 2022 11:31:37 +0000 Original-Received: by hermes--canary-production-sg3-65d7bd97b5-r89m2 (VZM Hermes SMTP Server) with ESMTPA ID 20c1ec887bdd086336cf09a063e41fcc; Fri, 08 Apr 2022 11:31:32 +0000 (UTC) In-Reply-To: <83y20fakwn.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 08 Apr 2022 14:12:41 +0300") X-Mailer: WebService/1.1.20048 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Received-SPF: pass client-ip=66.163.184.146; envelope-from=luangruo@yahoo.com; helo=sonic309-20.consmr.mail.ne1.yahoo.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 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:287952 Archived-At: Eli Zaretskii writes: > That suggests a different strategy: produce different input event > types from each such device. That'd leave the device dependency to > low-level code, and let the application level deal with event kinds > and not with device types. I think this is a better abstraction, if > it's possible/feasible. I don't think it's feasible, especially since there are too many different kinds of events, and with some of them those dfferent kinds of events simply cannot work. (Think single character keyboard events.) > We have been burned by modeling the application-level features on the > particular X implementation and low-level details. It took us > literally decades to get rid of X-specific code and features, let > alone API names, and move to exposing more general and more adaptable > APIs to applications. I was there when this hard lesson was learned, > and I'd rather we didn't repeat those mistakes. This API is not X specific at all; in contrast, an X-specific API would be to expose the list of device valuators and "classes", containing various flags. > Let's see from the get-go how this kind of functionality can be > expressed in device-independent and window-system independent ways, > and design the APIs accordingly. For that, we need to define what are > the aspects that applications would like to know about when dealing > with these input events, and then see how this could be abstracted or > generalized to any input system we support now and can envision to > support in the future. E.g., what about GPM and xt-mouse on TTYs? > what about window-systems that aren't based on X? etc. etc. When designing this feature, and why I purposely didn't design it based on the X concepts of device axises and classes, I worked from two directions: it should be possible to extract the type of a device (i.e. tell between a touchpad, a keyboard, a pointer, and a piano), and when possible (i.e. supported by the window system), it should be able to tell individual devices apart. The current API achieves the first goal by giving each device a "name", which contains enough information to determine the device type, and it also achieves the second goal by guaranteeing that the device names are unique to each device on window systems which support that, such as X and Wayland. Each window system can then define a function for `device-class', which returns the type of a device based on the name given to it. This feature was already implemented not just on X, but also on PGTK, which means it also works well with the very different input subsystems of Wayland and Broadway. I also wrote the code to make it work with NS, but it hasn't been tested yet. As for gpm-mouse and xt-mouse, their mouse movement is simply reported as the "core pointer" device, which tells any code that might want to perform a specific action based on the device type that the type could not be determined. > That doesn't mean you want to know about the device, it rather means > you want to know the keyboard layout: an entirely different aspect, > and not specific to any OS. You would still need to be able to identify the keyboard in order to know its keyboard layout, at least on X. > IMNSHO, it's too bad we rush into implementing such features without > any discussion. See above about the alternatives that, at least at > this time, seem much better to me than dragging the low-level device > type information to the application level, and in global stateful > variables on top of that. > Which once again favors the alternative that would work by defining > new kinds of events. That alternative has no compatibility issues. IMHO we cannot simply define new kinds of wheel events that purposely separate touchpads from mice, or mouse-movement events which separate trackpoints from mice. That would mean, from the perspective of the user, mice would continue to "work as before", but trackpads would not. Or a keyboard with a Greek layout would not work as it used to, while a keyboard with an English one would. It's also not possible to consistently give an individual keyboard a different keyboard layout under X, since the part of the keyboard extension for that only works with the obsolete version of the input extension, not the new one that some programs such as Emacs and most of the modern toolkits now support. I'm sorry if I rushed things, and I'd be happy to listen to any suggestions you might have. Hopefully, your concerns have also been addressed. Thanks in advance!